今天的软件相对之前的软件，需求越来越复杂，变化越来越快。软件架构不断的在演进，一方面是为了适应新的需求，一方面也在寻找软件简单化解决方案，通过架构的规范是的软件更容易维护，逻辑更清晰。所以架构一直在追求易维护、可扩展。往往软件在开发初期，架构合理、分层清晰，但进过多年维护后，系统变得一团乱码。

究其原因，主要是大家面向业务开发，直达业务实现，往往是脚本式，面向过程的开发，而不是从软件架构的角度去编写程序。其很大原因是大多数公司业务至上原则，业务为王，而要架构更好的软件，势必会花费更多的时间打磨，很多老板不愿承担这成本。

设计的很好的架构，为什么到最后就维护的一团乱码？真的是开发人员技能的问题吗？当然，从直接的原因看是因为开发人员的问题，但深究背后的原因，我们不难发现这是业务与技术之间的悖论。业务需求是在寻找业务之间的关联关系，业务是耦合的；而技术一直在寻找解耦，追求高内聚低耦合的架构（无论是现在的微服务、还是之前的分层架构、还是组件化模块化，无不在践行这个理念）。这两个追去看起来是天然不可调和的。如果开发人员只关注了业务的逻辑，按照业务思维去开发系统，那么系统自然而然就会走向耦合。那有没有一种可能，调和业务和架构之间的矛盾呢？答案是：有，DDD(Domain Driven Design,领域驱动设计)

MVC

我们先看看经典的MVC开发模型。

Controller负责业务逻辑的处理，Model代表和持久层交互的数据模型，View层负责视图展示。MVC架构其实很精粹，清晰，对于业务逻辑并不复杂，单一化的场景其实效率是很高的。但是随着业务的多变性和不断复杂化，MVC架构就会暴露以下问题：

  • MVC架构没有边界划分的概念和规范，在复杂的业务场景下会造成盘根交错的逻辑依赖，同时随着业务场景的不复杂化，代码意图会逐渐模糊，维护成本增加，对于系统的稳定性也会带来挑战。
  • MVC仅反映软件架构的分层，不定义业务语义的抽象和表达，对于业务知识的沉淀和复用性来说，不太友好。
  • MVC分割了数据和行为的表达，Model层（pojo）定义数据，Service层表述行为，会造成业务逻辑的首尾分离。

于是，为了解决以上问题，DDD的概念被提了出来。

DDD

这是一种解决复杂软件的思维方式，是一种思想；以业务为主导，自顶向下的进行业务领域划分，业务模型驱动架构设计。他的核心概念是Domain（领域）和 Model（模型）。一句话DDD是已经解决复杂软件的思想，核心思想是面向对象（OO），其核心概念是Domain（领域）和 Model（模型）。

DDD特点

  • 面向对象设计，数据行为绑定，告别贫血模型；
  • 降低复杂度，分而治之；
  • 优先考虑领域模型，而不是切割数据和行为；
  • 准确传达业务规则，业务优先；
  • 代码即设计；
  • 它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现业务和技术统一的架构演进；
  • 领域知识共享，提升协助效率；
  • 增加可维护性和可读性，延长软件生命周期；

分层技术架构

image-20240926124629799

用户交互层：负责向用户展现信息以及解释用户命令。RESTFul、rpc 请求或mq 消息等对外提供数据服务或指令服务。

业务应用层：很薄的一层，用来协调应用的活动和向领域层下达指令，它不包含业务逻辑，也不不保留业务对象的状态，但它保有应用任务的进度状态。 但在应用服务的实现中，它负责编排、转发、校验等。

领域层：核心层又称为模型层，本层包含关于领域的信息，负责表达业务概念。在这里保留业务对象的状态以及业务规则，即包含了该领域所有复杂的业务知识抽象和规则定义，对业务对象和它们状态的持久化被委托给了基础设施层。该层主要精力要放在领域对象分析上，可以从实体，值对象，聚合（聚合根），领域服务，领域事件，仓储，工厂等方面入手。

基础设施层：本层作为其他层的支撑库存在。它提供了层间的通信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用。主要有 2 方面内容，一是为领域模型提供持久化机制，当软件需要持久化能力时候才需要进行规划；一是对其他层提供通用的技术支持能力，如消息通信，通用工具，配置等的实现。

DDD究竟能带来什么价值

  1. 业务（团队）价值

（1）统一语言

（2）清晰的边界定义

（3）领域能力沉淀和复用

（4）面向业务建模

（5）设计和代码的等价

  1. 个人价值

（1）提升全局视野

（2）提升业务sense

（3）构建体系化思维

DDD缺点

虽然DDD在构建复杂软件模型上，有天然的优势，但同时这套方法论的缺点也非常明显：

  • 逻辑相对简单的业务和产品（比如一些小型公司的内部OA系统），用传统的MVC架构会更适合，构建也更快速。
  • 非业务形态产品和应用并不适合，比如bigdata。这类应用和业务专注于数据层的交互和适配，并无强业务语义类诉求，而DDD最关键的一部分就是业务领域的抽象和包装，切记，它解决的是负责业务问题。

参考阅读：

https://www.jianshu.com/p/5a5e62d5f994

https://new.qq.com/rain/a/20240523A04JCJ00

总结

一般这种笔记我很少评论，但今天不得不吐槽几句。DDD是个啥东西，貌似概论很多很复杂，咱们程序员写出代码，又快又好的跑在CPU上才是王道，成天整一堆饶舌烧脑的技术名词干啥，卷，往死里卷，然而这些东西对快速低成本的交付优秀软件产品没一点帮助，更多的时候是帮倒忙，把问题搞复杂了忽悠领导、老板、投资人。但要命的是，他们坑惨了天底下的码农。

记住：好的系统不是设计出来的，也不是写出来的，是改出来的，是在实践中不断完善出来的，适合的就是好的。

（完）