观点 | Opinion
今天我们还需要关注DDD吗？
12月8日，ThoughtWorks举办了第一届DDD（Domain-Driven Design，领域驱动设计）中国峰会，会上DDD领域的实践者分享了他们对于DDD的理解与应用。DDD是什么？我们认为它是比系统架构更高层次的概念，它是一种设计思想，很多时下流行的架构模式都是在这种思想影响下产生的，像最近备受关注的CQRS、微服务其实都存在DDD思想的影子；同时，DDD还在软件行业的其它方方面面影响不断。但是DDD本身相关内容并没有多少人去传播、去分享，这不禁让我们想问：我们需要去关注DDD吗？
DDD究竟意味着什么？在历史的进程中DDD的发展是怎么样的？它未来的发展前景如何？带着一系列问题，我们在会场采访了DDD资深专家、Event Storming之父Alberto Brandolini与ThoughtWorks资深咨询师王威。
DDD是什么？
要讨论需不需要关注DDD，首要的是先了解DDD是什么。Alberto认为，DDD是一种在面向高度复杂的软件系统时，关于如何去建模的方法论，“它的关键点是根据系统的复杂程度，建立合适的模型”。在Alberto当天的演讲“Why DDDMaters Today? ”中，他提到“在一个系统中，没有一个人能完全掌握系统的全貌”，在多人参与的系统中，DDD正是可以通过在不同角色之间进行协作，使参与者达成统一认知，对齐系统设计与程序实际所服务的业务领域。
图片源链接
具体来讲，DDD方法论在系统建模过程中，可以为团队中的各个角色提供一套统一语言，避免组件划分过程中的边界错位，完成领域图预演、需求分析、架构模型、代码模型、测试等工作。“统一语言”概念在DDD中极为重要，在一个系统的构建过程中，往往业务人员关注的是业务架构，而技术人员则关注系统架构的表述方式；在将业务架构映射到系统架构的时候，需要经过一层“翻译”工作；而业务只要发生变化，就会影响到系统，系统就要重新对业务进行翻译，这会使工作变得复杂、低效。在DDD中，使用一个统一语言，可以直接将业务架构与系统架构绑定，不需要进一步去翻译，从而增强系统对业务的响应速度。
“领域驱动设计”中的“领域”一词指的是要实现的软件系统所要解决的实际问题所处的整个领域范围，它不仅包括系统架构的相关问题，还涉及到系统所支持的业务等内容，但它是与具体的开发技术无关的。也就是说DDD关注的是要构建的系统中，关于所要解决的问题的业务、流程和数据等内容是如何工作的，在这些东西理清之后，DDD去构建出一个模型，接着再去选择具体的实现技术。DDD强调的是解耦具体实现技术，所以它可以迅速梳理核心业务逻辑。
DDD并不是直接给你建议某一个系统架构，它的执行结果是呈现一个方案，可以从这个构建出的模型中决定你去用什么技术来实现什么样的架构，进而来完成一个系统的设计。技术在这个过程中是被选择的，备选的各种技术只是像一个列表一样摆在眼前，它要根据你的领域需求来选择，比如“选择采用微服务架构”。
也正是因为它关注的是领域，而不是具体技术，所以DDD其实不仅可以应用在软件系统的开发中，也可以在其它领域，诸如测试体系的建设、公司的管理、需求变更的跟进和项目的管理。
总结起来，DDD的一个生命周期是这样的：在设计和实现一个系统的时候，这个系统所要处理问题的领域专家和开发人员以一套统一语言进行协作，共同完成该领域模型的构建，在这个过程中，业务架构和系统架构等问题都得到了解决，之后将领域模型中关于系统架构的主体映射为实现代码，完成系统的实现落地。而用什么方式去做领域模型的构建，方法是多样的，Alberto自己就为此发明了Event Storming（事件风暴），并成为了一种经典的DDD落地模式。
Alberto补充到：“为了方便理解，可以类比精益创业（Lean Startup），在我看来它是与DDD同个层次的概念，它也是一种能够通过快速对业务进行分析，快速去建模，支撑业务的模式。”
从微服务到DDD
DDD自2004年出现以来，其核心概念基本没发生什么变化，但是这些年来，DDD整体的传播与实践都在向好的方向发展着，Alberto认为有几个时间点使他印象深刻：
2003年，Eric Evans发布了影响深远的《Domain-Driven Design:Tackling Complexity in the Heart of Software》（领域驱动设计：软件核心复杂性应对之道）一书，DDD问世，开始受到关注；
2007年，Alberto开始接触DDD，他听了Eric的演讲，这让他很震撼，因为他在这之中了解到DDD对于处理界限上下文（BoundedContext）的思路很有价值。于是他开始深入了解DDD；
到了2011年，这是Alberto认为对DDD的发展至关重要的一年，这一年是DDD思想大爆发的时期。在这一年中，社区中聚集了一些DDD的思想领袖（Thought Leader）, Eric Evans自不必说，还有像《Implementing Domain-Driven Design》（实现领域驱动）的作者Vaughn Vernon、微服务巨匠Martin Fowler等人，他们聚到了一起，纷纷抛出自己的想法。大家突然之间发现，原来DDD可以做的事情有很多，它可以用来做CQRS，可以用来做测试体系的建设，也可以用来做项目的管理……DDD的应用场景变得多了起来。同时，Alberto自己在Event Storming方面的想法获得成功，很多专家在演讲中引用了他的这种DDD建模方式。他认为这一年非常有价值，业界大牛们就DDD展开了深入的交流。
而从国内来看，王威认为2014年微服务的兴起是DDD的一个重要里程碑。不可否认，很多人是因为微服务才了解DDD的。在听说了微服务架构之后，人们觉得采用微服务架构会让系统开发与运维管理变得简单高效，同时实现的系统会更加合理，更加高可用、高性能，但是当他们实际去做微服务架构的时候，有不少人会发现自己做得并不好，没法取得人们“吹捧”的那些效果，“就算用了微服务架构也不能解决他们的问题，反而带来很多开发与运维上的负担”。于是他们去咨询、去找方法，最后发现其实是自己划分微服务的方法出错了，这个时候才知道人们在谈论微服务的时候，其实都没有讲到一个点：应该用DDD的思想去指导微服务的实践。
是的，关于微服务架构怎么做，网上已经有很多相关理论和实践分享了，但是很少有人会说这个东西需要在DDD思想的指导下去做，在微服务的实践过程中，如果一开始就用DDD进行了全局模型设计，那么业务拆分、代码解耦等环节在实际架构建设时都是水到渠成的。而因为DDD使用统一语言来进行建模，这种高效建模、团队内部沟通无障碍和快速响应业务变化的特点会让微服务架构的实现更加简易。许多人盲目地去做微服务，如果在那之前他们先了解了DDD，那么在DDD的指导下，微服务或许又会有另一番美景；另一方面，许多人虽然不知道DDD，但是他们在系统构建的过程中，思想其实或多或少都会与DDD相符，那么，如果能够提前去了解DDD, “从DDD到微服务，而不是从微服务到DDD”，全面而系统地从头到尾以DDD的思想来操作，就能进一步降低微服务架构过程中行差踏错的可能性。
当然，人们谈论微服务而不涉及DDD，可能还有另一种情况，就是他们实际上就是在DDD的指导下完成了微服务架构，但是“由于在建模的过程中，核心领域就是公司的核心资产，公司一般是不会把这个东西拿出来分享的”，王威解释到。很容易理解，像大型电信、金融企业，他们的业务核心模型肯定是属于公司机密，不会对外分享的。这其实也就是如今虽然DDD已经可以被应用在各种业务场景下，但是我们很难看到DDD实践案例的一个重要原因。
不管从国外还是国内来看，目前DDD主要还是停留在社区层面，但是就像Alberto说的“去参加演讲，今年看到的是这些人，明年看到的基本还是这些人”，虽然社区仍然不大，参与者的忠诚度却是很高的。如今，国外有比较知名的DDDEurope、DDDExchange等会议，国内像这次也举办了“DDD中国峰会”，随着对DDD的研究、实践与传播，“这个圈子正在变得越来越大，我们相信更多的DDD实践将会被分享”。
看到这些变化，Alberto与王威都认为DDD迎来了发展的最佳时机。越来越多人关注DDD，而且出现了更多的企业去使用DDD的优势做业务，这使得目前DDD的境况不会变得更糟，但是Alberto提出了他的担忧：“我害怕DDD会不会最后变得像敏捷（Agile）那样。”王威进一步解释：“敏捷一开始其实是很好的，它的原则非常理想，大家对它的实践也非常广，但是目前来看敏捷，会发现每个人的实践都不同，大家对它的认知可能有分歧，甚至有些实践背离了敏捷的初衷。”两位都不希望DDD将来会发生类似的情况。
我们需要关注DDD吗？
DDD的思想在它问世的这十几年间已经深深地影响了软件行业的架构理论和各种实践发展，像CQRS架构、依赖反转、洋葱圈架构、EDA事件驱动架构和微服务架构等都能找到DDD的影子。DDD甚至影响了软件行业中的各个方面，比如在本次DDD会议上还可以看到，有的讲师从测试体系的建设、公司的管理、需求变更的跟进和项目的管理等方面分享了DDD的应用。
通常来说，DDD适用于任何规模、任何性质的公司，这是一种通用的、具有指导意义的方法论，因此它可以在各个业务场景里发挥作用。
王威认为，DDD作为一种方法论，我们更应该关注的是它能够帮助团队针对业务达成一个统一的认知。在这个业务变化节奏相当快的时代，系统架构是必须不断演进的，而DDD在这个过程中因为构建了团队的统一语言，使得在对业务的快速响应方面表现得出类拔萃，这是它的精髓，不管什么领域，只要有这种业务快速响应的需求，那么DDD都是适用的。以往想要启动一个系统架构设计的时候，需要3、4个月的时间去咨询，等待调研报告，但是如果以DDD的方式，那么2、3周就可以出一份Roadmap。王威说：“客户更看重的是DDD对整个业务领域统一的认知，以及对业务响应变化的能力，DDD快速启动的能力。”Alberto补充说到：“所有领域的企业都可以采用DDD, DDD应用最大的障碍就是去承认原先的架构并不是那么完善的。”
另一方面，在一些特定的领域，比如需要有人参与指导、进行技术交流，以及需要大量人力协作而容易导致秩序混乱的设计工作，DDD因为其关注业务问题域的特性，可以使得执行效果更好。
“而具体到创业公司，他们因为需要使用成本更低的方式去打入市场，所以使用DDD会让这个过程更加顺利。”Alberto认为这是创业公司的切入点。
所以回过头来看：我们需要关注DDD吗？不言而喻。Alberto与王威在这个问题上都回答的特别坚定：Sure，需要！
谈及如何去关注DDD, Alberto说他的经验是积极参与到本地社区中去，他认为这是一个很有效的方式，社区可以提供很多信息。同时他觉得看书并不是很好的方式，与其一个人看书学习，不如找一个人一起学习，确保你掌握了学到的东西。
而为DDD实践者构建一个社区，让关注DDD的人有一个交流平台，也正是此次DDD中国峰会的价值所在，举办方想以此在国内第一次正式地告诉软件设计从业者：DDD是在我们这个业务高度不确定的时代，解决业务问题，适应业务变化时需要采用的架构思想。
受访嘉宾介绍
Alberto Brandolini：全球软件巨匠，Event Storming之父。
王威：ThoughtWorks China咨询团队软件架构和企业转型咨询师。