DDD领域层多聚合共享的Enumeration类文件存放方案咨询

DDD Domain层共享枚举类/实体存放最优方案 #

优先选择方案3：在Domain/AggregatesModel下新建SharedEntities文件夹存放共享类型 #

其他两个方案的问题：

• 方案1：完全违反DRY原则，相同代码维护多份，后续修改League的枚举值、扩展属性时极易出现多份代码不一致的问题，维护成本极高，完全不可取。
• 方案2：会破坏聚合的边界独立性，Club和Match是两个完全对等的独立聚合，不存在从属关系，让其中一个聚合依赖另一个聚合的内部类型，会导致耦合混乱，后续聚合拆分、迭代都会被不必要的依赖限制，不符合DDD高内聚低耦合的设计要求。

方案3的合理性：

• 符合DDD共享内核（Shared Kernel）的设计规范：不属于任何单一聚合边界、仅作为通用类型被多个聚合引用的Enumeration类、通用值对象等，统一放在共享目录下，既保证代码仅维护一份，也清晰明确了这类类型的公共定位，不会模糊聚合边界。
• 可扩展性强：后续如果新增其他跨聚合共享的通用类型，还可以在SharedEntities下继续细分Enumerations、ValueObjects等子目录，文件结构长期保持清晰，维护成本低。

内容的提问来源于stack exchange，提问作者thomas_p