DDD(领域驱动设计)

学习并尝试用各种的设计模式去分析需求编写代码。但是在这一过程中并没有觉得重构或者代码的复用、优化觉得特别爽的感觉。怎么样都觉得这个代码还是不够好。

第一次接触到领域驱动设计的时候，是在看到了某个视频说到了这点，并且提出了领域驱动设计相关的知识。但是看完了还是觉得一脸懵逼，至少现在还是。想想就干脆写了文章进行自己的理解以及总结，可能很多理解偏差了。

 

了解领域驱动

软件开发不是一蹴而就的事情，我们不可能在不了解产品（或行业领域）的前提下进行软件开发，在开发前，通常需要进行大量的业务知识梳理，而后到达软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念。

DDD是一种以领域为核心的设计和开发理念。DDD通过维护一个深度反应领域的概念模型，以及提供可行的经过实践校验的大量模式来应对领域的复杂性。（它并不会降低复杂性）

领域驱动与数据驱动区别

 

通用语言

DDD分层架构

用户界面/展示层	负责向用户展示信息以及解释用户命令。
应用层	用来协调应用的活动，不包含业务逻辑，不保留业务对象的状态。但它保有应用任务的进度状态。
领域层	本层包含了关于领域的信息，这是业务软件的核心所在。在这里保留业务对象的状态，对业务对象和它们状态的持久化被委托给基础设施层。
基础设施层	其他层的支撑库存在。提供了层间的通信，实现了对业务对象的持久化。包含了对用户界面层的支撑库等。

 

 

 

层次	说明
controller	提供服务的访问层，目前采用RestController的方式，也做基础数据格式校验的业务。
service	对应上图中的services部分，主要做4类事情:1、开启事务与事务消息，2、适配并调用Executor层，3、业务拓展，4、多个Executor的编排组装。(协调应用的活动，不包含业务逻辑)
convertor	适配层，适配层的存在也是为了避免各层次间的强依赖,为了更清新的划分清楚层次，如command对象将不直接依赖vo对象，而是通过convertor或构造数据做适配
executor	具体业务命令的逻辑编排与执行，这是业务逻辑处理的关键地方,遵循CQRS分为Command与Query，executor是资源层的操控者。
extension	业务扩展层，可扩展多种业务实现，COLA提供了全局的策略规范。extension会在service层被调用
domain	洋葱图的核心部分:领域层，domain领域可细分为model与service(action)
event	event在架构图中属于资源层，event作为解耦系统的耦合度起到了非常关键的作用，同时也为解决事务问题提供了标准
pojo	数据dto对象，分为command/vo/co/ao... 等不同的dto对象
repository	资源层相对来说比较广泛，最基本的是对db的操作，对其他模块的操作(feign)，对搜索引擎或消息队列的操作都属于资源。可细分为:feign、db、search、message

领域对象的生命周期

每个对象都有生命周期，如图所示。对象自创建后，可能会经历各种不同的状态，直至最终消亡——要么存档，要么删除。管理这些对象时面临诸多挑战，稍有不慎就会偏离MODEL-DRIVEN DESIGN的轨道。

 

主要是为了在整个生命周期中维护完整性，防止模型陷入管理生命周期复杂性造成的困境中。解决这些问题，主要是靠AGGREGATE （[ˈæɡrɪɡət , ˈæɡrɪɡeɪt] 聚合）、FACTORY（[ˈfæktri]工厂）、REPOSITORY（

[rɪˈpɑːzətɔːri]存储库）三种模式。

首先是AGGREGATE（聚合），它通过定义清晰的所属关系和边界，并避免混乱、错综复杂的对象关系网来实现模型的内聚。聚合模式对于维护生命周期各个阶段的完整性具有至关重要的作用。接下来，我们将注意力转移到生命周期的开始阶段，使用FACTORY（工厂）来创建和重建复杂对象和AGGREGATE（聚合），从而封装它们的内部结构。最后，在生命周期的中间和末尾使用REPOSITORY（存储库）来提供查找和检索持久化对象并封装庞大基础设施的手段。