是否应该基于聚合（每个聚合 1 个模块）对域进行模块化？

Question

认为“模块结构和名称通常反映模型的早期形式 比课堂做的还要好”。 关于域模块化的最佳实践是什么？

例如：汽车发动机以及发动机和汽车客户的简单域。

聚合 1：引擎；

聚合 2：包含以下对象的汽车 Wheel、Position、Tire；

聚合 3：客户；

是否应该根据聚合根对域进行模块化？也就是说，汽车模块包含带有工厂存储库等的核心响应聚合，客户模块包含核心响应聚合等。

还是应该根据其他一些因素对其进行模块化？如果是的话，将聚合对象分散在不同的模块中是一件好事吗？

为了进一步澄清，这是我对 MikeSW 评论的回复：

知道领域可能会随着时间的推移而发展，因此应该在领域中实施一些敏捷思想。这导致模块化。对于敏捷开发的工作原理，我是新手，对 DDD 也不是很有经验。但我知道模块化应该遵循一些模式（这是我表达“最佳实践”的来源）。

首先，不清楚聚合是否真的应该代表用户故事中的一章（当然可以）。但也有一些情况并非如此。所以在这种情况下，一个模块应该包括聚合的一部分还是整个聚合（为了领域）

Answer 1

构建适当的域模块的一些基本规则：

• 模块应包含一个或多个聚合（聚合对象不应分散在多个模块上）；
• 模块应该与其他模块具有高内聚和低耦合（如果没有则更好）。尽量让它们彼此独立；
• 将任何事件、工厂、存储库、服务放入包含它们所绑定的聚合的模块中；
• 模块应该反映领域的关注点，命名应该反映通用语言。
• 如果有些模块是耦合的，尽量使依赖aciclic；
• 基于具有高内聚性的聚合和使用它们的上下文构建模块。
• 如果可能存在中等到高度耦合的模块，请创建一个父模块并将它们放入其中。

所以我的最终答案是否定的，模块不应基于聚合构建（每个模块 1 个 AR）。但基于领域概念和使用耦合聚合的上下文。

如果您认为我的回答无效，请添加评论（对于不赞成投票者）:)。还在等待更好的指点。如果没有提交其他答案，我会接受这个。