DDD

以下是个人对 DDD 设计理论的理解，及工作中怎么实践。

What? （什么是 DDD）

DDD 领域驱动设计（Domain-Driven Design），是埃里克·埃文斯于 2004 年提出的一种软件设计方法和理念。主要思想是利用业务模型来指导业务与应用的设计和实现。

Why？（为什么要这么做）

我之前参与的工作项目都是基于业务建模，数据层提供基于模型的原子操作，有些 SQL 厉害的开发可能会将某些业务嵌入其中，但这样不易维护和识别。建模之后进行分层架构，业务层基于模型开发去组织业务，有些可能会直接操作数据层，有些可能需要调用其它业务代码进行编排去实现一个完整的业务场景，可能这个完整的业务场景又会被其它业务场景调用，但是只是需要其中某些代码逻辑，可能直接加 if else，更优雅的可能会利用设计模式。总之这种分层不是很友好，因为程序员需要将模型和业务进行衔接。

How？（怎么做）

针对复杂的业务场景，如何让开发更专注自己的业务模块，核心领域。我们先将数据层这块抽出来，因为数据层仅仅是数据，没有任何行为，也称之贫血模式。数据层有专门的团队进行维护，利用面向过程的方式，将数据耦合行为（充血模式），提供对应业务领域的接口，这些接口实现类不仅是数据的载体，还有很多颗粒度非常小的行为。（BO 层），这一层屏蔽了数据的CRUD操作，对外只是一个个行为。中间有一层将这些行为组装成一个个功能（Method 层）。而业务层就是调用这些功能来实现对应业务领域（Service 层）。

这样做导致更偏向设计，怎么设计好行为，功能，因为这些是支撑业务的关键点，如果这些实现非常好，那么业务层可以更灵活的编排，开发就能更关注自己的业务。

以上是我对 DDD 的理解及实践。