前言
2004年领域驱动设计(DDD)被Eric Evans带到我们面前之后，一开始让很多人眼前一亮，但是这个高冷的思想一直在落地上不温不火，甚至很难被应用。我曾经在2010年左右看到过介绍‘领域建模语言’的介绍，其实那时候还不知道他的背后其实也是DDD的思想。2015年以后微服务的兴起让这个尘封多年的思想焕发了第二春。大家发现DDD居然和微服务的设计思路如此贴合。作为一名技术人员，平时工作中自然无法忽视这些业内最新设计思想和应用落地的实践。所以想着写一个系列，记录我个人对DDD的理解和应用，今天是第一篇。
正文
DDD全名(Domain Driven Design)领域驱动设计，它是一种从业务角度入手对软件开发进行思考的方式。传统的软件开发大多都会以技术思考开始。可以回想一下大多数的软件开发项目的方式，开发人员了解需求，之后信心满满的开始划分模块，设计数据库，考虑技术实现细节。模块的设计很多时候会贴合数据库的设计，基于数据考虑模块的划分。其实从这个过程中我们是用开发人员的思维去映射业务需求，将其转换为开发工程师能理解的方式。这个过程最后的效果，有时候业务人员会说：咦，这似乎不是我想要的；你理解错了。而我们往往也会回忆并考虑是不是自己真的理解的不对，是不是FS写的不够清楚，是不是BA搜集的需求不够准确。
了解敏捷思想的朋友其实不难理解，这并不能简单归结为理解或者搜集需求不准确，而是出现了信息丢失。DDD的思想是要尽量减少沟通中的信息丢失(这一思想和敏捷方法中的很多方式异曲同工)。DDD使用的方式更加简单粗暴——通用语言。简单说就是都说一种话，不要转换。他的具体做法是让开发人员和业务人员一起聊业务，在同一个语境下，通过讨论业务流程，共创一个业务模型(注意是业务模型，不是软件模型)。这个在实践过程中叫做“事件风暴”。敏捷圈的朋友有没有似曾相识？用户故事地图，用户影响地图等等，似乎有异曲同工之处。当然“事件风暴”可以有多场，为的就是大家对当前的业务模型达成一致，不需要翻译、映射、转换了。
那用什么来表示业务模型呢？很简单——便利贴。我们可以类似头脑风暴一样让业务人员和开发人员把自己理解的业务对象、业务事件、业务动作等各自放到便利贴上，然后随意组合用来沟通确定理解的一致性。同时这个过程中配合白板和马克笔来确定业务模型之间的先后顺序、依赖关系等。当然还可以将业务名词达成一致。这是一个可视化的共创过程。最终形成的将是一个业务和开发团队理解一致的“通用语言”模型。
DDD不是软件设计的银弹，不是简单地套用他的一些术语和实践就能把软件设计好。在我看来它更是一种思维方式的转变，如果把业务领域作为问题空间来看待，那么技术实现就是解决方案空间。我们习惯了直接使用解决方案空间来对待一切。却忽略了用户真正在意的是业务领域，他们需要软件来帮助他们应对业务挑战。所以DDD分成战略设计和战术设计两大方面。分别对应问题空间和解决方案空间。这样我们可以应用关注点分离来更好的聚焦。
前面我们在白板上，利用“通用语言”创建了若干领域模型，那么基于这些业务相关性，将一些业务模型归并到某一个业务领域中，这个领域就可以划分为一个”限界上下文”。不同限界上下文自然就形成了领域划分，而进一步的技术实现可以将他们划分成模块或者微服务。这个过程就是使用DDD进行软件设计的过程，它是从业务理解出发来逐步分解，最终才是技术实现。
从业务领域出发构建业务模型，之后再用技术实现模型的一个好处就是，这个模型能够自然的响应业务的变化，因为他们是一对一的关系。对于设计合理的领域对象这种变化会限定在限界上下文以内，不会出现涟漪效应。这不正是软件架构设计中一致在追求的效果吗？
总结
DDD和CQRS可以说是两个维度的东西，更没有谁比谁更先进之说。一种是设计思想，而另一种是实现方式。如果要实现好的CQRS架构，那么对应对象建模，哪些是命令哪些是查询对象，这些需要DDD的思维去设计来保证合理和健壮性。
本文中涉及了两个重要的DDD的术语：通用语言(UBIQUITOUS LANGUAGE)和限界上下文(BOUNDED CONTEXT)。感兴趣的小伙伴建议去阅读一下文末的参考书籍，在后续我的文章中也会介绍一些设计的概念给大家，并结合实际用例来说明。
参考书籍
《实现领域驱动设计》《领域驱动设计精粹》
