Overriding the same enumeration on every object oriented interface in C #

Question

In the old days, you often had a data module that was “low level”, independent of any other modules, but could be specified by them, for example, to get the enumerations that were used throughout the system.
Now we have object-oriented interfaces between modules, with calls and events. My question is, should we not have another place where the enumerations used throughout the system are listed, and should each interface that they need refer to these enumerations?

I have seen software where essentially the same enumeration is redefined on each interface, with translation functions when it is passed to another module.

So, for example, the interface IModule1 may have

enum module1_state { Unknown, NotRunning, Running } 

and IModule2 interface may have

 enum module2_state { Unknown, NotRunning, Running } 

where module 1, for example, collects data, module 2 performs some logic and then passes the data on to the third module, for example. GUI

In many cases, the enumerations will be really different, because, for example, the 2nd module can abstract some information that the 3rd module does not need and go to the simplified version.
But in some cases they are not different, and here it seems to me wrong that the enumerations are still redefined on each interface. An example is an action that is performed as part of several use cases. The action is the same, but depending on the use case, several small parts differ. An enumeration carrying the details of a precedent is transmitted through an interface to a high-level logic module, and then through another interface to a lower-level module. It is redefined on each interface and therefore must be translated into a high-level logic module.

There are other modules that simply migrate old, existing interfaces to newer ones, and again both interfaces redefined the same enumeration.

Can anyone tell me which one is better?

Answer 1

This is a matter of code organization, modularity, and reuse. For two modules, you may need to reuse the third one (think of projects in the same solution), but if they are part of separate limited contexts (mental solutions), they develop independently and usually must use separate definitions. The display you see should be normal between the individual restricted contexts, but the enumerations should be combined in one context.

Answer 2

The modern C # and Java DLL mechanism allows refactoring to move common things - in case of your question, enumerations - to a common DLL shared by others; as you point out, using this seems uninteresting.

However, as many of us know, the shape and architecture of code tends to reflect the shape and architecture of responsible organizations (Conway Law, http://en.wikipedia.org/wiki/Conways_Law ); the code applies not only to requirements, but also to authorship, control and fault (timetables and project management), as well as responsibility for maintenance; this makes the code structure reflect the structure of the organization chart.

(See also http://blogs.gartner.com/ray_valdes/2008/09/19/organizational-structure-vs-product-architecture-which-one-wins/ )

So, when I see something like a description, I wonder if there is any structure and politics in the game. Someone will have to own a common DLL, and no organization can be dependent on another; the result may be such replication.