打通架构与业务 领域驱动设计（DDD）加速企业产品持续演进

领域驱动设计（Domain Driven Design，DDD）和微服务架构（Microservices）是时下炙手可热的两个技术词汇。微服务可以把一个大型的单体应用程序和服务拆分为多个微服务，从而满足服务等级协议，让应用的架构逻辑更清晰而好用。比如，现在越来越庞大的 微信 、支付宝这类应用里的服务模块被大量应用，可扩展单个组件而不是整个的应用程序堆栈。

随着微服务的火热，领域驱动设计（DDD）的架构思想也越来越被企业和研发团队所重视。 一个典型的例子是，几乎每一个在尝试微服务的团队和产品，都从领域驱动设计（DDD）的实践当中受益。而领域驱动设计（DDD）的核心诉求就是能够让业务架构和系统架构形成绑定关系，从而当我们去响应业务变化调整业务架构时，系统架构的改变是随之自发的。

近日，2017领域驱动设计中国峰会（2017 DDD China Conference）在北京举行。这次活动由国内领域驱动设计（DDD）思想和实践的领军者——ThoughtWorks的架构咨询师们组织发起，为国内的领域驱动设计（DDD） 实践者们提供了一个互相交流、分享自己团队的成功经验的机会的平台，使得领域驱动设计 （DDD）的架构思想能够在国内被更多人所认知，从而形成更大的规模效应。

何为DDD？

领域驱动设计（DDD）组织架构上实现了面向业务领域的弹性可伸缩，对系统功能和业务场景进行领域抽象，并采用分层设计，使得系统针对业务应用的可扩展性大大增加。同时，更好地完善产品架构，避免了按照功能划分导致的服务碎片化和相同概念的重复开发工作，让每个业务以及功能都能平滑落地、快速迭代。同时能够让技术和业务化繁为简，让开发人员轻松地完成工作，为公司沉淀出可以复用的通用域，积累业务领域深度知识，拓宽个人的认知边界，成为所属领域专家。

DDD凭借其强大的多任务处理能力，让很多工程师重新发现了其价值。在微服务架构实践中，人们大量地借用了DDD中的概念和技术。比如一个微服务应该对应DDD中的一个限界上下文；在微服务设计中应该首先识别出DDD中的聚合根；还有在微服务之间集成时采用DDD中的防腐层设计等等。可以说DDD和微服务有着天生的默契，程序员在做微服务架构时，总能从领域驱动设计中得到启发。

每个系统环境都有自己的语言，使用一个独立实现和接口与其它有界的上下文来交互调用。领域驱动设计（DDD）的最小单元是领域模型（能够精确反映领域中某一知识元素的载体），通过通用语言，在有界的上下文中实现清晰而明确的收集需求，为理解错综复杂的业务领域提供帮助。

ThoughtWorks咨询和设计总监肖然告诉记者，DDD的想法是让我们的软件实现和一个演进的架构模型保持一致，而这个演进的模型来自于我们的业务需求。领域驱动设计（DDD）的核心是建立领域模型，确保业务逻辑都在一个模型中，其最显著的优点是减少沟通成本，发现潜在需求，加快业务和产品的迭代速度。

业务与架构

DDD思想是关注业务与架构之间的关系，那么业务与架构之间是一种什么关系呢？

ThoughtWorks高级咨询师余丹妮认为，领域驱动设计强调以业务为核心，对业务领域进行抽象和建模。业务驱动架构的演进发展，同时架构也会反作用于业务。成功的DDD方法运用是贯穿系统的整个生命周期的，这个过程中业务和技术的协作是持续发生的。

应该说，架构是为了解决业务的问题而产生的，没有了业务，架构就没有了存在的前提。在解决同一个业务问题的前提下，更高效，更低成本的架构，会淘汰低效，高成本的架构。所以，DDD让架构更高效，打破了架构和业务之间的隔阂，其流行的意义就在此。

作为领域驱动设计国内最早的一批实践者，阿里盒马架构总监张群辉表示，阿里是典型的业务驱动架构，并不会无端地创建一种架构，虽然阿里是一个技术驱动的公司。“阿里会根据业务的变化来关注架构的走向，围绕 商业 愿景进行技术创新。DDD就是一种可以选择的方式，让业务平台的效率得到提升，实现业务流程化处理和智能决策。”

众所周知，盒马作为阿里巴巴新零售的排头兵，第一次真正意义上涉入零售行业，创建中国新零售模式下的供应链体系，颠覆传统ERP是盒马技术最近几年不停探索的重点。DDD的引入加速了这种愿景的实现。

张群辉表示，阿里对于DDD的引入并没有强制要求，但是身在盒马，非常有必须引入DDD。并且盒马关注供应链，DDD的引入有助于业务的迭代演进，架构师团队可以更好地实现创新，收益非常明显。

DDD的落地

余丹妮认为，企业引入DDD是一个渐进式的梳理过程，并不是一蹴而就。软件架构设计的实质是让系统能够更快地响应外界业务的变化，并且使得系统能够持续演进。DDD让软件架构设计更完美。

而张群辉认为，一个企业引入DDD对于架构师团队水平提出了更高的要求，同时企业需要明白DDD需要一个较长时间的投入才会产生效益。“很多时候，DDD的引入与架构师的情怀关系很大，你是否打算将自己的团队打造成一个DDD化的团队。”

DDD让团队中各个角色（从业务到开发测试）都能够采用统一的架构语言，从而避免组件划分过程中的边界错位；让业务架构和系统架构形成绑定关系，从而建立针对业务变化的高响应力架构。

肖然表示，在战略层面，DDD非常强调针对业务问题的分析和分解，通过识别核心问题域来降低分析的复杂度。在战术层面，DDD强调通过识别问题域里的不同业务上下文来进行面向业务需求的组件化。最后在实现层面利用成熟的技术模式屏蔽掉技术细节的复杂度。

所以说，通过DDD对复杂的软件问题进行控制，而一个好的领域模型是控制复杂问题的关键。DDD的价值在于提供一种通用的语言，使得领域专家和软件技术人员联系在一起，沟通无歧义。

结语

DDD并不是软件架构设计的唯一选项，但是其在当今时代却有着非常重要的现实意义。业务与架构的融合是企业进行业务创新的关键，DDD则打通了架构与业务之间的“桥梁”，让业务与功能能够持续迭代演进，为企业的发展提供了动力。