域是否应该基于聚合(每个聚合一个模块)进行模块化？

Question

认为“模块结构和名称通常比类更早地反映模型的形式”。域模块化的最佳实践是什么？

例如:一个简单的领域的汽车，发动机和客户的引擎和汽车。

合计1:发动机；

集料2:装有以下物体的汽车--车轮、位置、轮胎；

总计3:客户；

域是否应该基于聚合根进行模块化？也就是说，car模块包含有工厂仓库等的协应者聚合，客户模块包含协同应答聚合等。

还是应该基于其他一些因素将其模块化？如果是，那么将聚合对象分散到不同的模块中是件好事吗？

为了进一步澄清，以下是我对MikeSW公司的评论的答复：

知道领域可能会随着时间的发展，一些敏捷思想应该在领域中实现。这导致模块化。对于敏捷开发是如何工作的，我还不太熟悉DDD。但是我知道模块化应该遵循一些模式(这就是我的表达“最佳实践”的来源)。

对于初学者来说，还不清楚聚合是否真的应该代表用户故事中的一章(当然，它可能)。但是在某些情况下，它不是这样的。因此，在这种情况下，模块应该包含部分聚合或整体聚合(为了域起见)。

Answer 1

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

• 模块应包含一个或多个聚合(不应将聚合对象分散在多个模块上)；
• 模块应该具有与其他模块的高内聚性和低耦合性(如果没有则更好)。设法使他们彼此独立；
• 将包含聚合的事件、工厂、存储库、服务放在模块中；
• 模块应该反映领域的关注，命名应该反映无处不在的语言。
• 如果一些模块是耦合的，试着使依赖关系成为现实；
• 基于具有高内聚力的聚合并基于使用它们的上下文构建模块。
• 如果可能存在中等到高度耦合的模块，则创建一个父模块并将它们放入其中。

所以我的最后答案是不，这些模块不应该基于聚合(每个模块一个AR )构建。但是基于领域概念和使用耦合聚合的上下文。

如果你认为我的回答是无效的(对于选民来说)，会添加一条评论:)。还在等待更好的指示。如果没有提交其他答案，我将接受这个答案。。