认识达内从这里开始

领域驱动设计随着互联网的不断发展而被越来越多的程序员掌握，而本文我们就通过案例分析来简单了解一下，领域驱动设计入门知识分享。

为什么要制定参考工程架构

不同团队落地DDD所采取的应用架构风格可能不同，并没有统一的、标准的DDD工程架构。有些团队可能遵循的DDD四层架构，或改进的DDD四层架构，有些团队可能综合考虑分层架构、整洁架构、六边形架构等多种架构风格，有些在实践中可能引入CQRS解决读模型与写模型的差异化等等。即使无法制定通用的、标准的工程应用架构，但为团队制定一个遵循领域驱动设计思想的参考架构依然有价值。基于以下原因：

为团队实践DDD的战术设计提供可以快速开始的工程参考

参考工程大量的命名和结构决策，显式的体现DDD的相关理念，有利于团队对DDD的战术实现达成一致认知

同时，参考架构有助于沉淀团队对领域驱动设计的一些思考和佳实践

参考架构的考量因素

虽然无法制定完全通用的DDD参考架构，但制定某个特定上下文下的参考架构却具有可行性和实践价值。针对于上下文的选择要尽量贴合实际的工程实践场景并考虑多维度的因素。

本文所述参考工程架构遵循以下原则：

遵循领域驱动设计的本质思想

充分考虑业务系统建设特点

依赖小化，保持轻量

希望工程参考架构能涵盖以下范围

分离业务域与技术域

参考架构要遵循技术和业务隔离的特性，可以参考多种架构风格。业务与技术关注点的分离并不是DDD独有的特点，在六边形、整洁架构、洋葱架构中都遵循了这一重要原则。

多限界上下文场景

大多数团队基于DDD进行微服务拆分的时候，特别是系统建设初期，对单个微服务应用内的限界上下文的粒度需要权衡。由于团队组织架构因素及微服务成本问题，单个应用容纳的限界上下文一般是多个(理想情况下是1:1)。这些限界上下文随着后续的逐步迭代有可能会迁移至独立应用。因此，参考架构将多上下文的应用场景作为重要考量因素。

明确的组件、职责边界及依赖关系

支持领域报表场景：报表场景在业务系统较为常见，DDD并没有体现该场景的处理方式。作为工程参考架构，还是希望能够从实际业务出发，体现对写模型和报表模型的显示支持

外部依赖小化：需要排除不必要的依赖，保持工程架构的轻量化

参考架构剖析

应用的多上下文结构

基于以上原则，参考工程考虑单个应用内多上下文的场景，以期在模块化和服务粒度及成本间进行权衡折衷。应用架构对多上下文的支持的逻辑示意图如下所示，在解决方案域对限界上下文进行识别和划分之后，基于其业务内聚性和关联性，把多个上下文实现单个工程应用中。单个应用内的多个限界上下文间可能存在交互，交互的形式可以是基于事件驱动，也可以是基于进程内调用。采用事件驱动的方式上下文间的耦合性对低一些，但一般需要引入事件总线的支持，额外组件的引入必然会导致复杂性的上升。进程内调用则耦合性会高一些，但从实现角度复杂度会低一些。具体选择哪种方式开发人员可以基于实际情况进行权衡。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。