Domain Driven Desgin 领域驱动设计

对于偏业务开发的同学，做了一段时间后，可能会思考业务架构怎么做更合理，有没有什么理论支撑？那么，DDD 是一种思路。

DDD是Domain driven design（领域驱动设计）的简称，是一种软件设计和开发的方法论，特别适用于复杂业务领域软件设计和开发。

针对DDD的架构设计，《实现领域驱动设计》提到了几种架构风格：六边形架构、REST架构、CQRS、事件驱动等。在实际使用中，落地的架构并非是纯粹其中的一种，而很有可能户将上述几种架构风格结合起来实现。

（注：我们目前做的技术设计，大都是需求驱动设计。这和我们的工作方式有关，主要是基于产品经理的需求来出技术设计，而对业务和问题的本质理解不一定深入，或者不是那么关注。）

核心概念

什么是领域（Domain）

一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。比如电商平台、普通电商系统，这种都属于网上电商领域，只要是这个领域的系统，那都有商品浏览、购物车、下单、减库存、付款交易等核心环节。

通常我们说，要成为一个领域的专家，必须要在这个领域深入研究很多年才行。因为只有你研究了很多年，你才会遇到非常多的该领域的问题，同时你解决这个领域中的问题的经验也非常丰富。很多时候，领域专家比技术专家更加吃香，比如金融领域的专家。

界限上下文（Bounded Context）

通常来说，一个领域有且只有一个核心问题，我们称之为该领域的『核心子域』。在核心子域、通用子域、支撑子域梳理的同时，会定义出子域中的『限界上下文』及其关系，用它来 阐述子域之间的关系 。界限上下文可以简单理解成一个子系统或组件模块。

领域模型

DDD是一种基于模型驱动开发的软件开发思想，强调领域模型是整个系统的核心，领域模型也是整个系统的核心价值所在。每一个领域，都有一个对应的领域模型，领域模型能够很好的帮我们解决复杂的业务问题。

领域驱动设计（Domain-Driven Design）分为两个阶段：

• 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；
• 由领域模型驱动软件设计，用代码来实现该领域模型；

由此可见，领域驱动设计的核心是建立正确的领域模型。

领域通用语言

领域驱动设计的一个核心原则是使用一种基于模型的语言。使用模型作为语言的核心骨架，要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样，这种语言被称为『通用语言』。

（注：比如，我们写代码的时候，会感觉确定“名词”的英文翻译是一个很苦恼的事情。如果在前期沟通中把这些明确了，可以节省很多时间。）

领域建模时思考问题的角度

我们设计领域模型时不能以用户为中心作为出发点去思考问题，不能老是想着用户会对系统做什么；而应该从一个客观的角度，根据用户需求挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律作为出发点去思考问题。

领域模型是排除了人之外的客观世界模型，但是领域模型包含人所扮演的参与者角色，但是一般情况下不要让参与者角色在领域模型中占据主要位置，如果以人所扮演的参与者角色在领域模型中占据主要位置，那么各个系统的领域模型将变得没有差别，因为软件系统就是一个人机交互的系统，都是以人为主的活动记录或跟踪；比如：论坛中如果以人为主导，那么领域模型就是：人发帖，人回帖，人结贴，等等；DDD的例子中，如果是以人为中心的话，就变成了：托运人托运货物，收货人收货物，付款人付款，等等；

因此，当我们谈及领域模型时，已经默认把人的因素排除开了，因为领域只有对人来说才有意义，人是在领域范围之外的，如果人也划入领域，领域模型将很难保持客观性。领域模型是与谁用和怎样用是无关的客观模型。归纳起来说就是，领域建模是建立虚拟模型让我们现实的人使用，而不是建立虚拟空间，去模仿现实。

分层结构

• User Interface —— 用户界面层。提供与用户/调用者交互的接口.
• Application —— 应用层。薄薄的一层，定义软件要完成的任务。对外为展示层提供各种应用功能，对内调用领域层（领域对象或领域服务）完成各种业务逻辑。应用层不包含业务逻辑
• Domain —— 业务领域层。表达业务概念、业务状态信息及业务规则，是业务软件的核心
• Infrastructure —— 为其他层提供通用的技术能力，提供了层间通信；为领域层提供持久化机制。

主要流程

总结起来，DDD 的一个生命周期是这样的：

• 在设计和实现一个系统的时候，这个系统所要处理问题的领域专家和开发人员以一套统一语言进行协作，共同完成该领域模型的构建，在这个过程中，业务架构和系统架构等问题都得到了解决，
• 之后将领域模型中关于系统架构的主体映射为实现代码，完成系统的实现落地。而用什么方式去做领域模型的构建，方法是多样的

模式图

总结/思考

适合：复杂业务场景，而且比较明确。

DDD 应该不适合未知领域的探索。

参考文档

[1] http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html [2] https://www.cnblogs.com/netfocus/p/5548025.html [3] http://www.cnblogs.com/daoqidelv/p/7492322.html [4] https://mp.weixin.qq.com/s/NMtbP8X2AB0dbW3RzWrdhg [5] https://mp.weixin.qq.com/s?__biz=MzIwMzg1ODcwMw==&mid=2247487260&idx=1&sn=87de0617a7b0cfd6d56d248e79b429fe&chksm=96c9b97ca1be306a9cfda048a99a57abb77b3ac4270740cd391d04c7f692ee92e6c76c2016f9&scene=21#wechat_redirect