了解 DDD 领域驱动设计

了解 DDD 领域驱动设计

最近在做些项目重构的工作，了解了一些应用架构的知识，总结如下

好的架构代码是简单的、美的，对代码要又追求

• DDD 是一种更清晰的应用架构
  • 优点：使用面向对象的编程范式，代码关注点拆分的很清晰，架构思想也清晰简单
  • 难点：使用面向对象编程、对领域建模，牵扯到很多的新概念和方法论，在项目中使用需要经验
• 三层架构有什么可以吸取 DDD 的经验吗？
  • 不足：业务流程和业务对象是混淆在一起的，如果抽象，分类分包设计的不好容易导致代码堆积，难以维护
  • 可以借鉴的思想：在分类、分包、方法、接口上要谨慎，学习面向对象的思想，让类、service 对象是独立自恰的

应用架构定义：解决项目中 代码要如何被组织的问题，通俗讲就是代码如何分层、分包的问题，通过分层分包达到 聚焦代码关注点，分离业务复杂度 的问题，使代码逻辑更加清晰、更易维护。

编程范式定义：如何组织程序结构以及如何处理数据。常见的编程范式包括面向对象编程、函数式编程、命令式编程等

DDD（领域驱动设计，Domain-Driven Design）应用架构：一种软件开发方法论，强调以业务领域模型为核心，通过领域模型紧密协作来构建复杂系统的架构。

三层应用架构：将应用程序分为三个独立的逻辑层：表示层（Presentation Layer）、业务逻辑层（Business Logic Layer）和数据访问层（Data Access Layer）。这种分层结构有助于分离关注点，提高代码的可维护性、可扩展性和模块化设计。

• 核心代码位置的不同
  • 在 DDD (领域驱动设计) 中，需要将重点放在领域层（Domain Layer）进行业务逻辑和规则的实现。服务层（Service Layer）主要负责协调和调度各个领域对象之间的交互。
  • 三层架构中业务逻辑都堆积在 Service 层
• 编程范式的不同
  • 领域驱动中使用了面向对象和 命令式编程两种方式
    • 通过面向对象抽象领域模型
    • 通过命令式编程，编排业务逻辑
  • 三层架构中使用过程式编程（命令式编程），
    • 过程驱动的代码，重点是抽象能力，沉淀函数，并用编排引擎串联执行过程，来实现业务逻辑。

Go 的 DDD 工程化项目实践

简化代码模块设计：两种高效编程范式

八年实战经验，解读DDD思想内核

• 第一件事，它提供了一种给“应用层”或“服务层”分类的方法。
• 第二件事：保护好你的代码边界，否则它会变得腐化且难以维护。
• 第三件事：第三件事：让模型回归业务的本质。

现在再来看这张DDD的典型架构图，你可能会更加理解DDD的思想内核，这是一种面向领域的设计方法，把领域层（业务规则）包在最里面，保护好边界，避免领域层被污染。DDD通过这样的方式降低建模和实现的复杂度。

这里或许会有人要反驳了：我就是喜欢用数据建模的方式，CRUD简简单单，我的系统跑了这么多年了，支撑了几百亿的业务也没什么问题。

我会这样回答你，软件工程的解空间通常不止一个，问题不在于”是否能解“而是在于”解的复杂性“，你的建模越贴近业务（问题域），你的解法将会越贴近最优解。

事实上这是我认为DDD推行的最大阻力，这里面存在一个认知陷阱：当你有一套理论能解决现有问题时，你很难接受一个新的理论且那个理论好像更有道理，这意味着你之前长期坚持的稳固的知识体系要被打破，而且你越牛，这个陷阱就越深。