领域驱动设计(DDD:Domain-Driven-Design)

  因为我司框架是基于DDD+插件的模式,基于学习需要所以初步学习了DDD,并且请教了DDD的专家宽宽大佬.

DDD定义：领域模型应该捕抓“业务规则”或者“领域逻辑”（business rules/domain logic），而应用模型则捕抓“应用逻辑”（application logic）DDD把模型分成了四层：
* UI层，负责界面的展示。
* 应用层（），负责业务流层。
* 领域层（），负责领域逻辑。
* 基建层（），负责提供基建。

分类的依据：越往上，预期变动月频繁；越往下，预期变动越小。UI只管展示，基建层（包括数据持久层）提供持续存储、网络传输等等基础建设，都没有业务的参与。领域层与业务层区别?
1. 领域逻辑就是显性的专业知识，是相对容易理解和学习的部分;
2. 领域逻辑是提纯、通用的规则;

例子理解：领域建模好比如把业务流程拆分到对应业务参与人员上，财务、销售、采购、决策、客服，领域划分粒度随着业务流程细化不断变小，例如财务；拆分为出纳、会计、审计如果觉得划分到出纳、会计、审计就能满足业务了，就开始写class了。这些还不是具体业务。。。具体业务是这样的：用户买保险！用户买保险涉及到的流程会有多方参与，销售开单、客服跟单、通知会计开具发票（如果需要）、出纳收银等等领域上各个领域自己负责的事情，可以称为职责。

宽宽大佬简单解释：

有两种处理方式：一种是“上帝视角”有两种处理方式，一种是“上帝视角”即业务的所有细节，有一个上帝全部清楚，这样的编程的结果就是一个核心的逻辑流程调用所有其他的功能
这么做的前提是，能有这么一个知晓一切的上帝。并且所有附属功能都很简单（比如就是读取db，生成excel等）如果业务问题符合这个假设，这么编程是最好的，因为业务逻辑非常清晰容易理解。就算你拆分成一块一块的，还是要一起用。耦合不因为你拆了就没了。
但另外一个场景是，每个业务流程极端复杂。复杂到无法出现这么一个上帝知晓一切细节。上帝只知道大概。这时每个业务单元都可以单独实现成一个模块/服务。让上帝来调用。这么做的前提是，每个业务单元都相对独立，并不会因为上帝的视角的改变而改变。（举个例子，比如你要去政府申请开公司，政府说我的部门说3天审核完，你想3个小时就完事，政府不会因为你的意愿就给改成3小时。）其实这个就是我们日常工作的模拟，怎么做整体是可控的。业务逻辑简单就直接开搞。业务逻辑复杂就拆分成独立的组件来协作。

然而，大多数人用不了DDD是因为业务逻辑没有那么复杂。Web就是这样的，一个数据db读出来，处理下输出完事，而比如做一单保险的试算就麻烦大了；另外一方面是，业务逻辑拆解和性能需求是相反的拆得越细碎，越难做性能优化，这和政府效率不高很搭配）