领域驱动设计

本文是根据原文 http://www.cnblogs.com/netfocus/p/5548025.html 学习后的笔记。

一、概念理解
什么是领域（Domain）？
一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。
同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。

什么是驱动（Driven）？
1）领域驱动领域模型设计；2）领域模型驱动代码实现。

什么是设计（Design）？
1）领域驱动领域模型设计；2）领域模型驱动代码实现。我们只要保证领域模型的设计是正确的，就能确定领域模型可以解决领域中的核心问题；
同理，我们只要保证代码实现是严格按照领域模型的意图来落地的，那就能保证最后出来的代码能够解决领域的核心问题的。
这个思路，和传统的分析、设计、编码这几个阶段被割裂（并且每个阶段的产物也不同）的软件开发方法学形成鲜明的对比。

概念总结：
领域就是问题域，有边界，领域中有很多问题，需要理解、拆分、细化；
任何一个系统要解决的那个大问题都对应一个领域；

通过建立领域模型来解决领域中的核心问题，模型驱动的思想；
领域建模的目标针对我们在领域中所关心的问题，即只针对核心关注点，而不是整个领域中的所有问题；
领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值；

通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题；
领域模型是系统的核心，是领域内的业务的直接沉淀，具有非常大的业务价值；

技术架构设计或数据存储等是在领域模型的外围，帮助领域模型进行落地；

二、理解领域、拆分领域、细化领域
理解领域
对领域内的各种业务场景和各种业务规则非常清楚，对这个领域内的一切业务相关的知识都非常了解。有能力表达出系统该做成什么样子。只能靠沉淀领域内的各种知识，别无他法。

拆分领域
以电商系统为例
会员中心：负责用户账号登录、用户信息的管理；
商品中心：负责商品的展示、导航、维护；
订单中心：负责订单的生成和生命周期管理；
交易中心：负责交易相关的业务；
库存中心：负责维护商品的库存；
促销中心：负责各种促销活动的支持；

细化领域
梳理领域概念：梳理出领域内我们关注的概念、概念的关系，并统一交流词汇，形成统一语言；
梳理业务规则：梳理出领域内我们关注的各种业务规则，DDD中叫不变性（invariants），比如唯一性规则，余额不能小于零等；
梳理交互场景：梳理出领域内的核心业务场景，比如电商平台中的加入购物车、提交订单、发起付款等核心业务场景；
梳理业务流程：梳理出领域内的关键业务流程，比如订单处理流程，退款流程等；

三、领域模型设计 后续再根据具体场景补充

四、DDD的适用场景
复杂业务场景，我们强烈建议使用DDD代替事务脚本（TS: Transaction Script）。
TS–贫血模式，里面只有数据结构，完全没有对象（数据+行为）的概念，这也是为什么我们叫它是面向过程的原因。
然而DDD是面向对象的，是一种知识丰富的设计（Knowledge Rich Design），怎么理解？就是通过领域对象（Domain Object），领域语言（Ubiquitous Language）
将核心的领域概念通过代码的形式表达出来，从而增加代码的可理解性。这里的领域核心不仅仅是业务里的“名词”，所有的业务活动和规则如同实体一样，都需要明确的表达出来。

五、作者心愿
我的老婆在家，计划开一家淘宝小店卖童装。目前对于淘宝店铺的装修和基本设置没有经验，请了解这方面的朋友们指教。可以留言，也可以发我QQ邮箱：1425733292@qq.com，小可不甚感激。