业务变化不息，架构演进不止 第四届领域驱动设计峰会线上开启

DDD的特点与价值在于它定义的模式，限界上下文与聚合是DDD的核心模式。限界上下文是架构层次的自治单元，是业务能力的重用而非模型的重用。而微服务的协作就是限界上下文的协作，领域驱动设计成为显学，进入黄金时代。

单体架构（Monolithic Architecture）是一种将所有功能打包在一个容器中运行的设计风格，一个实例中集成了一个系统的所有功能。从中大型项目的业务形态、复杂度及响应速度等维度看单体架构时可以发现它存在扩展性差、无法实现复杂业务、技术升级困难、开发效率低等问题。

张逸表示，常见的区分单体架构和微服务架构的做法并不正确，虽然没有限界上下文的单体架构可能导致“大泥球”，但是单体架构也要通过业务能力进行纵向切分。如果单体架构通过限界上下文进行边界控制，其实可以降低微服务架构风格的演化成本，也能规避过度微服务化带来的技术风险。

另外，张逸认为，领域驱动设计存在四大“天生不足”，比如领域驱动设计缺乏一个规范的过程指导，使得其缺乏可操作性；领域驱动设计没有匹配的需求管理体系等，为此，我们需要领域驱动设计统一过程，确保DDD的落地实施。

领域驱动设计在大型遗留系统改造中的实践

自领域驱动设计和微服务概念提出至今，越来越多的互联网巨头以及传统行业都开始对自己的遗留系统进行微服务改造，通过把系统拆分为更加灵活、有业务边界上下文、松耦合的服务来应对快速变化的市场。

IBM资深应用架构师于静在主题演讲中介绍了一个有着二十年历史并支撑百万交易额的电商平台如何通过DDD方法华丽转身的实践，从这个案例我们了解到遗留系统进行DDD改造过程中的点滴经验。

于静表示，为了加速数字化转型与业务模式创新实现，遗留系统的改造会面临很多难题，比如交付速度慢、应用架构不满足快速迭代需求、技术受限、维护成本高、业务流程复杂等。而在改造过程中，现有业务不能停，同时过程难控制、结果难验证等问题也非常突出。

为此，遗留系统改造实施需要确立目标与制定策略、业务梳理、服务改造、集成迁移测试、反馈。在DDD指导下，企业需要通过事件风暴对业务讨论，审视现有的业务逻辑，逐步用新应用程序和服务替换特定功能段，增量迁移旧系统。随着旧系统功能的更换，新系统最终取代了所有旧系统功能。

于静说，企业在遗留系统改造中应该遵循“先锋队、树立模范、大部队”的阶段性原则。具体来说，“先锋队”阶段是挑选规模较小、功能简单，业务较为独立的功能模块进行改造，随着老系统的功能越来越多的被微服务系统所代替，老系统也最终被替代。需要注意的是，当发生新老系统的功能切换时，应该逐步切换用户流量，对用户尽量透明，使得改造过程过渡平滑。

当中台遇上DDD，如何设计微服务？

当前，中台、微服务是业界关注的热点话题。如果将两者放到DDD的背景下，如何建立DDD、中台和微服务的统一语言？如何将三者融合完成协同设计？《中台架构与实现：基于DDD和微服务》作者、极客时间《DDD实战课》专栏作者欧创新在主题分享中回答了这些问题。

欧创新表示，从企业架构角度来讲，业务中台属于业务架构的范畴，业务中台重构的过程本质是基于复用目的的企业级业务架构重构。在业务量不大的时候，我们用传统的集中式架构就可以解决复杂问题。而当面对海量互联网业务比如双十一，企业原来的架构就不足以解决业务和应用的扩展性问题，因此我们需要将原来大的问题域拆小，将单体应用拆分为微服务，进而上云。所以，DDD和微服务都是解决复杂问题的设计思想。

在DDD概念里，如果只从业务架构角度分析的话，中台本质上是从领域到更细的子域划分过程中的一个桥梁，只从业务领域角度分析，它可能对应DDD领域中的某一个核心子域或通用子域。

对于DDD与中台和微服务的关系，欧创新认为，中台本质是领域中的某一个子域，需要抽象并标准化，按照单一职责原则建立可复用的领域模型。微服务是中台最佳技术实现。DDD是一种可以同时指导中台业务建模和微服务设计的方法论，遵循高内聚低耦合的原则，完成从业务端领域建模到应用端微服务实现的无缝落地。

我们看到DDD和中台设计两种知识体系的融合需要建立两者通用语言，团队通用语言也是DDD不断强调的内容。一般对于小的项目我们可以直接从问题域开始事件风暴，完成领域建模。而对于企业级中台而言，业务领域非常大，我们需要做好顶层设计，划分子域，确定中台的大致边界，然后基于这个边界开展事件风暴，划分限界上下文，完成领域建模，它是一个自上而下的设计过程。

“DDD博大精深，但DDD也不是万能的‘银弹’。将中台和DDD视作一种思维方式和设计思想，结合企业实际情况灵活运用才是王道。 ”欧创新说。

DDD从战略设计到代码落地的三阶段方法

ThoughtWorks总监级咨询师杨云指导过多个DDD实施项目的落地，在峰会的主题演讲上杨云系统介绍了如何将DDD建模在大规模开发团队的情况下确实的落地到代码层面。

为什么企业觉得DDD落地难？杨云表示：“首先，因为DDD进入了更深层的应用。DDD从战略层面的应用进入到战术落地层面，而不再仅仅停留在子域划分、微服务划分等。其次，参与建模的人，从业务专家和架构师级别的技术专家，深入到产品经理、软件工程师等执行具体事务的人员，面临在百人以上开发团队大项目上保证代码按照模型落地的难度。最后，DDD建模的投入和交付时间点的矛盾、DDD建模投入的即时性和DDD模型收益的长期性之间的矛盾。”

在DDD落地方面，企业需要对战术级别的建模提供更具体、更模式化的指引。对于大规模项目，设计更明确、与代码实现直接相关的微观模型。提供更好的工具降低DDD模型建设和维护成本，提高模型和代码一致性。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!