1、领域驱动编程
友链
1.1、基本概念
领域驱动设计，我们先扣一下字眼。
驱动：我们可以理解为促进，促使的意思，那么领域驱动设计也就是，领域来促使软件系统架构设计
领域：我们可以将其理解为业务问题的范畴，领域可大可小，对应着大小问题的边界。
简单的说，领域驱动设计就是将业务上要做的一件大事，通过推演和抽象，拆分成多个内聚的领域。而之所以称之为领域，是因为我们在设计时将其通用性非常好，能够适配不同的复杂的情况。
举个例子：我做了个支付系统，这个支付系统不仅仅我们公司能用，其他公司搬过去也能用，或者说改造的成本很低。这个系统，可以说是在支付领域上的优秀系统。又比如若依，pig等热门的常见的权限管理系统，市面上很多公司项目都是基于他们项目进行开发的，因此他们也可以称之为权限管理领域的优秀系统。
那么，如果某个项目在该领域上达到极点，甚至说所有的涉及该领域的需求都可以用他，那么这个项目通常也可以称之为框架。
产品驱动设计？
我认为与领域驱动设计概念相对的就是产品驱动设计，也就是说，针对我产品的需求，做crud来实现需求，就达成了产品需求来促使软件系统架构设计条件。事实上，领域驱动设计的目的是提高产品的复用性或者是通用性，产品能够更低成本的二次开发、迭代和复用
为什么要做领域驱动设计？
前面我们多次提到了，领域驱动设计的目标就是将产品做成一个领域内的，其通用性和复用性很高。以此来设计的产品具有二开便捷，复用性强的特点。适合于频繁维护迭代，领域推广复用等需求的产品。
深入理解领域
领域可大可小，而越小的领域驱动编程的产品，越好做。
举个例子：我们做一个支付领域的产品，支付领域下可以分为多个比他小的领域，比如说订单系统领域，分账领域，风控领域。。。。
领域越小的产品越好做，怎么理解呢？
我提出一个问题，创建对象领域的领域驱动产品设计的产品你知道吗？
我相信你其实能够想到，spring。我认为spring就是创建对象领域最优秀的产品，但凡是java中需要创建对象，都可以使用spring。这正如我们上面提到的，设计该领域的需求都可以用它，那么他就可以被称之为框架。
而对于spring本身的领域而言，无非就是创建对象，将创建对象的控制权，交由spring来做。而我们自己做，通常来讲只需要使用 new 关键字或者使用反射即可。那么，创建对象这个领域，可以称之为是小之又小了。
领域驱动设计的关键
我们后面会提出很多领域驱动设计的模板，思想，套路，但请你记住，不一定要按部就班的实现，或者强行套用。这只是一种设计规范。但一定要遵循高内聚，低耦合的思想。ddd仅仅只是对你的一种指导。
1.2、概念归纳
DP（Domain Primitive）：抽象并封装自检和一些隐性属性的计算逻辑，且这些属性是无状态的。在DDD里，DP可以说是一切模型、方法、架构的基础。他是特定领域、拥有精确定义、可以自我验证、拥有行为的对象。可以认为是领域的最小组成部分。DP有三条原则：让隐性的概念显性化，让隐性的上下文显性化，封装多对象行为
Entity：抽象并封装单对象有状态的逻辑
Domain Service：抽象并封装多对象的有状态逻辑
Repository：抽象并封装外部访问逻辑
领域驱动设计业务的指导过程：
- 首先对处理的业务问题进行总览
- 然后领域对象（Entity）进行划分，明确每个领域对象包含的信息和职责边界。并进行夸对象，多对象的逻辑组织（Domain Service）
- 接着在上层应用中更具业务描述去编排Entity和Domain Service
- 最后再做一些下水道工作，对下层数据访问，RPC调用一些实现
下水道工作是指需要系统外部依赖的组件，比如数据库，RPC接口，当我们需要替换数据库或者请求别的接口的时候，如果我们在上层应用层实现他们，那么在这些依赖发生改变，如RPC接口调用其他公司的，数据库换成Oricon，就需要修改应用层代码。并且我们需要抽象成接口依赖，注入接口自动装配实现来达到防腐的木点。来避免下游变动导致的应用层变动。
接口属于防腐层，实现属于腐烂层。