领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名：领域驱动设计—软件核心复杂性应对之道)一书。，书中提出了“领域驱动设计(简称 ddd)”的概念。
领域驱动设计一般分为两个阶段：
-
以一种领域专家、设计人员、开发人员都能理解的“通用语言”作为相互交流的工具，在不断交流的过程中发现和挖出一些主要的领域概念，然后将这些概念设计成一个领域模型；
-
由领域模型驱动软件设计，用代码来表现该领域模型。领域需求的最初细节，在功能层面通过领域专家的讨论得出。
领域驱动设计告诉我们，在通过软件实现一个业务系统时，建立一个领域模型是非常重要和必要的，因为领域模型具有以下特点：
-
领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反应了我们在领域内所关注的部分；
-
领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物，书本，应聘记录，地址，等；还能反映领域中的一些过程概念，如资金转账，等；
-
领域模型确保了我们的软件的业务逻辑都在一个模型中，都在一个地方；这样对提高软件的可维护性，业务可理解性以及可重用性方面都有很好的帮助；
-
领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造；
-
领域模型贯穿软件分析、设计，以及开发的整个过程；领域专家、设计人员、开发人员通过领域模型进行交流，彼此共享知识与信息；因为大家面向的都是同一个模型，所以可以防止需求走样，可以让软件设计开发人员做出来的软件真正满足需求；
-
要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型；
-
为了让领域模型看的见，我们需要用一些方法来表示它；图是表达领域模型最常用的方式，但不是唯一的表达方式，代码或文字描述也能表达领域模型；
-
领域模型是整个软件的核心，是软件中最有价值和最具竞争力的部分；设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化；
-
“领域”到底是什么？
所以“领域驱动设计”这句话后两个词很好理解，但“领域”到底指的是什么？
DDD通过分析业务，最终构建成一个个“领域”，设计出一个个富含业务行为的、饱满的“领域模型”。
在DDD里，“领域”指的就是一块业务范围。比如在一个电商系统中，可能会有“商品领域”、“订单领域”、“物流领域”、“仓储领域”等等。DDD通过战略部分指导我们根据业务划分出业务领域，并区别出哪些是核心领域，哪些是支撑领域和通用领域。这个我们会在本系列后面的文章中详细解释。
“领域模型”指的是业务的载体对象，比如“商品”、“订单”等等。这些对象具有一些有业务含义的方法，比如“商品.加入购物车”方法。我们把主要的业务逻辑内聚在领域对象里，这样一个操作要做的事情就变得非常清晰，并且易于维护。
简单来说，“领域”和“领域模型”能够更直观地表现业务，把业务真正落地到系统架构和代码设计上。
为什么需要DDD？
“即使我们的软件中没有bug，也不能表示我们设计的软件模型本身就是好的”。使用DDD，能够让我们的软件设计更加合理，但不止于此。
对于一个业务复杂的系统而言，使用DDD有如下好处：
- 开发者和熟悉业务的人一起工作，加强团队间不同角色的合作；
- 能够帮助业务人员和开发人员梳理清楚复杂的业务规则；
- 开发出来的软件是能够准确表达业务规则的，设计就是代码，代码就是设计；
什么时候需要使用DDD？
使用DDD是有一些成本的，你的团队成员需要去了解DDD的一些基础知识，最好还需要有人做过DDD方面的实践，有一定的经验。
做任何事情都需要衡量成本和收益，技术方案的选型也不例外。DDD有一定的成本，但也能带给我们显而易见的收益。
一般来说，DDD适用于“业务复杂”的且“需要维护和扩展”的系统。
首先，我们来看看什么叫业务复杂。试想一下，如果你的系统只需要对几个简单的表进行CRUD，那你不需要使用DDD，甚至都不需要开发一个应用程序，直接使用一个数据库客户端可能就能解决问题。
从经验上来看，如果你的系统有30个以内的业务操作或用户故事，那也是没有太大必要去使用DDD的。而如果超过三四十个，软件就会有一定的复杂性，这个时候就可以考虑使用DDD了。
另一方面来说，即使现在这个软件并不复杂，但后续会进行开发和扩展，在可以预见的将来，它会变得复杂，那也可以考虑使用DDD。而一些初创公司，它们或许只需要一个简单的产品来快速测试市场反馈，后续并不会继续开发和维护，而是考虑重新购买或者从头开发的话，那也没有必要浪费成本去使用DDD。
所以再次总结我们什么时候需要使用DDD呢？业务复杂且需要长期维护的时候。
总结
其实纵观全文，可以发现DDD的核心就是一个词：业务。DDD的一切工具、实现都是以业务为中心，从业务展开的。所以如果要想实施好DDD，一定要认清业务的价值，关注业务，理解业务。
参考书籍：
- 领域驱动设计—软件核心复杂性应对之道
- DDD（领域驱动设计）blog.csdn.net/wwd0501/art…
- wangchengming.blog.csdn.net/article/det…
