Re-defining the same enum on every object oriented interface in C#

Question

In olden days, you often had a data module that was "low level", did not depend on any other modules, but could be referenced by them, for example to get enums that were used throughout the system.
Now we have object oriented interfaces between modules, with calls and events. My question is, shouldn't we still have one place where enums that are used throughout the system are defined, and these enums should be referenced by every interface that needs them?

I have seen software where essentially the same enum is re-defined on each interface, with translation functions for when it is passed on to another module.

So for example, the interface IModule1 might have

enum module1_state
{
    Unknown, 
    NotRunning,
    Running
}

and the interface IModule2 might have

enum module2_state
{
    Unknown,
    NotRunning,
    Running
}

where module 1 for example collects data, module 2 performs some logic, and then passes data further to a 3rd module, e.g. a GUI.

In many cases, the enums would be genuinely different, because for example, the 2nd module can abstract away some information that isn't needed by the 3rd module, and pass on a simplified version.
But in some cases, they aren't different, and here it seems wrong to me that the enums are still re-defined on each interface. An example is an action that is carried out as part of several different use cases. The action is the same, but depending on the use case, several small details are different. An enum carrying details of the use case is passed over an interface to a high level logic module, and then on over another interface to a lower level module. It is redefined on each interface, and therefore must be translated in the high level logic module.

There are some other modules which just translate older, existing interfaces to newer ones, and again, both interfaces have re-defined the same enum.

Can anyone tell me which is best practice?

Answer 1

This is a matter of code organization, modularity and reuse. It might make sense for two modules to reuse a third (think projects in the same solution), but if they're part of separate bounded contexts (think solutions), they evolve independently and should generally use separate definitions. The mapping that you see should be normal between separate bounded contexts, but the enums should possibly be unified within the same context.