DDD这些概念已经火了很长时间，截至目前也是热度不减。各个公司也都有相应的落地实践，尤其是在中台建设时。笔者接触DDD比较早，无奈由于当时的认知和能力问题一直没太弄明白如何落地，后来也就没在关注了。直到公司几年前制定了中台战略，笔者有幸参与了从0到1的整个过程。过程中公司也给了足够的试错空间，非常幸运的有了足够的环境和时间从理论知识、方法论到落地实践方方面面都实践了一遍。

笔者之前总结过一份5W多字的笔记，但由于时间比较仓促，多数内容是记录给自己看的，正好最近有些时间，开一个此系列的文章，分享下笔者这些年DDD理论落地的经验，希望能与您共鸣。此系列预计包含6大章、35小节讲述DDD在中台建设的实践。

首先笔者先阐明一个观点，中台或是DDD需要适合的土壤和人群，尤其面对研发同学笔者不建议初中级研发同学去研究这方面的理论知识，这里没有褒贬的意思，只是很容易陷入一学就会，一用就废的处境，如果形成了错误的知识体系就百害而无一利了。

另外这个领域并不是写在PPT上的文字，需要静下心来踏实的一步一步脚印走，同时也需要一定的外部环境支持，比如好的研发文化、足够复杂的系统、足够多的业务种类也能最大化发挥其优势进而起到提效和降本的作用如果有读者现在也在进行此方式的研发工作，建议不时的复盘下，最根本的要回答出以下两个问题：

• 所谓的中台，现在是在做能力还是在做功能？
• 中台建设的短期和中长期的目标是否足够清晰？
• 研发流程有了哪些改进，研发效能是否有所提升？

以上几个问题是笔者在实践过程中踩过的坑，曾经一度认为这东西就是形势主义，劳民伤财。其实不然，与其系统技术方面的改变来说，认知和思维的改变可能更能决定其成功与否。

软件设计的核心之一是架构设计，评判架构的优略最重要的标准是其与所支撑业务的匹配程度和适度的扩展性。流行的一句话：”没有业务的架构设计全是耍流氓“，实话，但也悲壮的让人心疼。

比架构设计更核心的应该是业务模型的设计，实际上任何一本关于软件设计的书中都会提及”技术+业务”，这四个字或许也是每个软件人职业生涯中一直追求的目标。然而反观我们的很多系统，技术对业务的表述往往局限在了一张优美的架构图上，而真正能反映业务的模型很多时候却被一个个事务脚本所代替。这种设计无所谓好还是坏，从支撑业务稳定运行的角度来讲是合格的。但从业务发展的角度来讲，上述软件架构的适应能力是有待商榷的。

从各种报道和权威统计数据上可以看出，现阶段互联网行业的多数业务都或多或少面临市场饱和、流量红利消失、资本投入的减少、获客成本的提高等不利因素，打破这一局面需要划时代的创新，然而真正意义上的创新本质上需要以大的技术变革推动，没有新技术的介入往往需要稳固市场或开展新业务模式。这个背景下的新业务基本上的是基于原有成熟业务模式进行删减和增加个性化场景进而孵化出来的，新业务不会经过技术、甚至是产品阶段就会直接被市场验证。所以快速实现、快速试错在一定程度上成了这阶段业务创新的重要需求。

快速的业务试错和越来越多的个性化需求对于软件系统的设计要求是非常高的，如果现有系统的模型能很好的表述业务，即使谈不上加速至少不会成为创新瓶颈。但是对于”大泥球”般的复杂软件系统尤其是稳定的已经对接了很多线上业务的核心系统的冲击可能是毁灭性的。改造这种”大泥球”般的系统使其能很好的表述业务并不是一件容易的事，需要一套科学的指导方法和与之配套的落地方案，这就是本文档中提及的解决方案DDD领域驱动设计（Domain-Driven Design）。

DDD并不是什么新的知识，早在几十年前就已经提出了，其核心思想是围绕真实业务场景构建领域模型进而解决复杂系统开发。幸运的是DDD除提供了一套完整的设计方法外，还分别从组织架构、技术架构、工程管理、代码落地等方面分别给出了指导方法和实践指南。

DDD分为战略和战术两方面：战略主要讲述的是站在组织的视角定位业务以及应用间集成所采用的策略（非公司级的经营战略）；战术是战略的代码映射，详细包括模型的分析、构建、整合优化等。

DDD之于我

100个读者心中有100个哈姆雷特，这是在实践DDD以后的直观感受。DDD的受益人群比较广，甚至软件开发全周期中的所有角色都可以从中得到指导。基于此刻笔者对DDD的认知，它确实可以解决一些日常工作中遇到的问题：

• 全局的业务视图，降低认知负担，拉齐业产研多方对业务的理解，统一顶层设计；
• 统一通用语言，提高沟通效率，加速知识的沉淀，可用于需求的沟通和模型的定义；
• 限界上下文，系统间解耦的重要依据之一。同时综合组织架构等因素，采取不同的集成策略，减少由于组织的调整带来的冲击；
• 与业务一致的模型设计和代码映射，规范编码的同时也可缩短新员工的上手周期；