今天我们还需要关注DDD吗？

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