知识卡片
聚合目录是代码重组的最小移动单元
内容
领域层的domain目录由一个或多个独立的聚合目录组成,每个聚合目录内部有统一标准的子结构:entity(聚合根、实体、值对象及其业务方法)、event(事件实体与相关逻辑)、service(领域服务、工厂服务)、repository(仓储接口与实现)。书中强调把一个聚合的所有代码集中放在同一个目录里,主要目的不只是为了业务上的高内聚,更是为了给未来”以聚合为单位在不同微服务之间重组代码”这件事打下便利的基础——有了清晰的聚合代码边界,无论是把某个聚合从一个微服务里剥离出来独立成新服务,还是把某个聚合从一个微服务搬迁到另一个微服务,都只需要操作这一个目录,不需要在代码库里到处搜寻散落在各处、原本属于同一个聚合的代码片段。聚合之间要求保持松耦合和低关联,聚合间的服务调用应该通过上层应用层来组合完成,而不允许聚合直接调用其他聚合的领域服务。这个设计提醒:代码目录结构不只是给人看的组织形式,它本身可以被设计成直接服务于”未来需要频繁重组”这个已知需求的工具——聚合目录的价值,很大一部分要等到真正发生架构演进、需要拆分或迁移代码的那一刻才会兑现。
参考来源
- 位置:第14章《如何用DDD设计微服务代码模型》"14.2.2 各层代码目录","3. 领域层"(源文件:_epub-src/OEBPS/Text/chapter4-3-2-2.xhtml)
- 结论依据:原文说明"将聚合所有的代码放在一个目录里的主要目的,不仅是为了业务的高内聚,也是为了未来微服务之间聚合代码重组的便利性。有了清晰的聚合代码边界,你就可以轻松地实现以聚合为单位的微服务拆分和重组",直接支撑本卡片结论。
- 原始内容:将聚合所有的代码放在一个目录里的主要目的,不仅是为了业务的高内聚,也是为了未来微服务之间聚合代码重组的便利性。有了清晰的聚合代码边界,你就可以轻松地实现以聚合为单位的微服务拆分和重组。聚合之间的松耦合设计和清晰的代码边界,在微服务架构演进中具有非常重要的价值。