领域驱动开发（domain driven development）

链接： https://www.zhihu.com/question/56332619/answer/250971065

什么是领域驱动开发

将问题抽象为一个领域解决方案。并针对此领域（即抽象）进行开发的方式。

领域驱动开发解决了什么问题

解决两个问题1，变化。2，复杂度。

原则上适用于任何软件，特别适用于一些特别复杂，变化特别频繁的系统——尤其是迭代很快又很复杂的稳定要求又很高的互联网金融核心系统。

在这些业务系统中，常常糅合了支付，账务，会计等多业务领域的知识；同时糅合了通讯，协议，安全，编码等多种技术领域知识；如果涉及到多系统对接，甚至还要常常面临多种不同的解决方案的整合。

怎么办？

1，问题分层，转化为业务领域，技术领域。通过协议或者接口先屏蔽技术上的差异性。各层只关注自己的问题。

2，问题分块，同层问题转化为A,B,C等不同业务领域；定义他们彼此服务整合的方式。

3，关注要素，忽略细节 ；关注抽象，忽略具体；……

————————其实就是分而治之，化繁为简；抓住主要矛盾的过程。

领域驱动开发的威力

领域模型的核心是抽象和分治（less is more）

例子1：linux很神奇的管道的原理么(命令通过|无限组装）？

1，任何io操作都是文件

2，任何文件有三个默认io方向（stdin,stdout,stderror）

3，pipe的作用是链接上下文件，转化stdout stdin

ls *|grep abc 的底层原理就是

ls * (输出到stdout) （转化上一个的stdout为下一个的stdin） grep abc( 从stdin）

顺便说一下 不单单你看到的文件 linux下几乎啥都是file（命令，设备……），你想想这样玩的威力吧

再说一下应对复杂度的威力，说一下金融届有名的三户模型

卡客账，卡即支付工具的抽象，客即人的抽象，账即资金的抽象。

1，存折换成卡，卡换成app，核心不需要任何变动

2，红包，优惠券，信贷账户怎么玩？其实就是账户之间增加父子结构而已。

（红包，优惠券，信贷账户特征是有额度；但都是假的，真实发生交易的时候才操作真实资金账户；其他情况下不作为资金处理：解决方案就是设置父子账户，子账户即使红包信贷账户，对子账户的操作实际操作的是户账户资金。不需要开发）

这三户模型的抽象，也有助于解决金融产品一些快速的创新和复杂的产品设计——前提是开发和产品理解这个抽象，我真见过再设计一大套红包，信贷账户表，搞一大堆专门处理他们逻辑差异性的金融系统——这样就导致整天忙死了，并且问题不断。

人的抽象在支付上用处不大，但是在风控上意义重大。风控的本质上就是对人的理解和博弈。不论啥卡欺诈，账户欺诈，设备……最终都是要挂到这个概念上的，不论任何规则，模型，也最终都要落实到这个模型上的。

卡客账：金融业务和金融风险的完美建模有没有。

领域模型开发要注意那些

1. 领域划分，定义
2. 概念定义
3. 概念职责，行为，服务
4. 概念之间关系
5. 应对变化

这就是领域驱动开发。相对于具体业务驱动开发而言的。