DDD(1)-DDD的相关概念

目录

1、领域驱动设计-DDD的概念

1.1、正反例对比

1.2、好差代码对比

1.3、名词解释

1.4、DDD四层架构

2、DDD落地方法

2.1、领域建模-战略

2.2、微服务拆分和设计-战术

---

1、领域驱动设计-DDD的概念

DDD不是架构，是方法论

1.1、正反例对比

反例

比如一个Web交易系统，凭直觉开发。使用MVC短平快第一个版本没有问题。第二个版本无法交付。比如电商单体页，页面静态化，但是有人开始加ajax,越加越多，项目混乱

正例

用代码体现业务模型，开发人员、邻域专家质检沟通质量得以改善。领域专家（业务专家）怎么设计的，代码就怎么设计。领域专家参与到代码设计中。

特点

系统不是按照MVC划分层次，而是按照业务架构划分成一个个domain,应用程序domain之间的自由组合。一个微服务有多个domain组成。

总结

要在代码中体现领域思想，强调领域专家和开发人员一起参与系统建设

1.2、好差代码对比

差代码示例

 

好的代码目标

单一职责原则:

开放封闭原则：对外开放，对内修改封闭

依赖反转原则：面向接口依赖，而不是实现类（必须要接口）。

1.3、名词解释

限界上线文：定义领域模型的边界和业务范围

平血模型：就是我们平时用的pojo，只带get、set不带业务方法

充血模型：实体带业务方法，DDD采用这种

防腐层：

1）在架构层面，通过引入防腐层有效隔离限界上下文之间的耦合；

2）防腐层同时还可以扮演适配器、调停者、外观等角色；

3）防腐层往往属于下游限界上下文，用以隔绝上游限界上下文可能发生的变化；

1.4、DDD四层架构

 通过以上是不是发现一个问题，系统多出了很多类，本来可以一个类实现的，现在衍生除了好多类。可以看出小型项目体现不出优势，考虑到以后的变动，比如数据库会不会编，三方服务会不会变。

改造后的好处

2、DDD落地方法

分两步

1）领域建模-战略

2）微服务拆分和设计-战术

2.1、领域建模-战略

step1:业务角度出发,事件风暴（分析流程等）

step2:划分业务领域边界,建立基于业务语言的限界上线文

step3:建立领域模型

step4:映射到微服务

限界上线问与子域的关系

子域：业务角度

限界上线文：技术角度

2.2、微服务拆分和设计-战术

step1:事件风暴找出实体和值对象

step2:从实体中找出聚合根

step3:将业务关联紧密的聚合根、实体、值对象组合在一起形成聚合

step4:结合业务将多个聚合划分到一个限界上下文中

step5:分层设计（后面会讲到）