领域驱动设计菜鸟概念篇 – 汪明鑫的个人博客

前言

DDD & CQRS + 分层 & Interface + module = 优雅的代码 + 设计模式 = clean architecture

如果说以前的MVC是傻白甜，现在的DDD就是深似海

MVC更像是打着面向对象的旗子写面向过程的代码

组内的项目基于领域驱动设计重构，目前已经到第二期阶段，对于我来说相当难，但也算是一个挑战和机会

Eric的《领域驱动设计》这本书也是真的好难啃。。。争取慢慢看完，然后再看一本《实现领域驱动设计》

本篇主要介绍相关概念，下篇会介绍基于cola的DDD实践

年前最后整理几篇领域驱动设计相关文章就回家过年喽！

什么是领域驱动设计

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

他究竟为何物？

他不是一个像Spring那样的技术框架，他也不是设计模式，我觉得他更是一套编程的方法论，是一套规范

DDD 核心思想是通过领域驱动设计方法定义领域模型，

从而确定业务和应用边界，保证业务模型与代码模型的一致性。

DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概

念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是

架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清

晰的领域和应用边界，可以很容易地实现架构演进。

核心点

领域驱动设计最核心的两个点：

1、通过领域模型为业务知识建模，领域模型作为业务、产品、技术团队沟通的统一语言。

2、通过一整套设计规范和实现框架来帮助我们确保软件实现与领域模型保持一致。

贫血模型 VS 充血模型

【贫血模型】

纯POJO对象，没有包含任何业务规则实现，⼀般与Database的表结构对应

比如我们的MVC架构，业务逻辑都在service做

贫⾎模型是软件复杂性的根源

【充血模型】

对象 = 数据 + 行为

把与模型相关的行为也收拢过来

充⾎模型能够解决业务软件复杂性

DDD对象

先主要介绍下Entity、 ValueObject

聚合、界限上下文等我取取经再说吧，

个人觉得聚合和领域服务等在简单的场景下还是不需要的，用了反而加大工作量，降低代码可读性

比如我们目前重构的项目中就没有用到聚合和领域服务

实体 Entity

有标识区分

如上图的Customer

当两个对象的标识不同时，即使两个对象的其他属性全都相同，我们也认为他们是两个完全不同的实体。

比如不同的人身份证不同，就算同名

值对象 valueObject

当一个对象用于对事物进行描述而没有唯一标识时，那么它被称作值对象

关注于属性

如上图的Address

再比如颜色等属性

CQRS

分离查询操作和写操作

分层架构

基于分层架构，将业务规则抽取到领域层，领域层基于充⾎模型构建

关于依赖倒置和更多细节我们下篇再说

领域

领域驱动设计流程

DDD规范

下篇我们会介绍下cola

我觉得cola框架是DDD实践的一个规范指引，但并不是限制死死的条条框框，团队按照cola根据情况制定规范，我觉得都可以在一定的限制下突破条条框框只要团队按照统一的风格来写就行规范的东西没有定论，选择适合的就可以并不说要这几个模块，就不允许其他模块的存在，必须并入cola规定的模块并不是说一定要依赖倒置，一定要要gateway，一定要命名成repository,还是命名成tunnel, 这些东西都是可以商定的，不是死的