领域驱动设计——小记

为什么会有分层架构设计？？

本质上分层架构是为了一种约定，明确代码、服务之间的调用关系。通过定义类型的职责和依赖原则来明确不同代码之间的存放位置以及代码之间的调用关系，从而保证系统的稳定运行。

PRD的重要性？？

在设计团队架构前要先明确PRD，一个好的PRD文档使用依赖最少的背景知识就可以让所有参与者理解的词汇、语言、逻辑表达模式达成统一。

如何让一篇PRD做到最好？？

1.建立通用语言
在团队中构建统一的词典，包含业务术语、词汇含义、功能点含义等，来达到团队共识的目的。
2.使用图来表达
使用不同的图来展示不同的业务角度，例如对象关系UML图、领域模型图、数据流图、时序图等。

领域驱动设计中的领域到底是什么？？怎么设计？？

领域的含义就是明确边界的范围，这么解释可能不是很明显。
在领域驱动设计中有两部分空间，业务问题空间&解决方案空间，领域是在业务空间中将业务问题划分到各个范围中并由解决方案空间中的系统模块来实现解决。领域在这过程中主要描述了解决问题要在那些范围中解决，不能在哪些范围中解决。并描述业务之间的关系，从而解决更复杂的系统性问题。
在设计上，首先要明确两点，定义领域职责，定义领域关系。
而定义领域职责需要遵循两点：
1.同一个领域能够独立完成特定业务需求。
2.对应的业务问题不可与其他领域重复。

定义领域关系时要遵循：
1.领域之间要尽量做到无关系或代价最小的关系。
2.尽量避免领域之间的依赖关系，如果频频产生依赖关系说明领域分的颗粒度过小。
3.分割关注关系，降低领域之间的耦合。

接下来就是如何正确的对业务建模？？

在建立模型时需要对实际业务做思考，模型是否将业务行为描述准确，模型中的业务目标中必要信息是否缺少，在扩展字段设计时是否真的用得上。
模型标识设计：
自增主键、计算值主键、组合主键
模型信息设计：
字段名称要明确表达含义、字段含义不应因为状态而变化
模型状态设计：
区分状态类型确认维度数据、实例在使用时不会处于同一状态下、避免将不同的类型状态放在同一个字段里、状态设计要固定
模型行为设计：
在设计行为时尽量用业务行为描述模型行为、且明确区分不同行为。
模型事件设计：
命名应该清晰地描述事件触发场景、在事件递进过程中要有完整上下文信息

DDD分层架构分为：分层架构、洋葱架构、六边形架构，菱形对称架构
我这里只举两个例子

简单的分层架构例子

1.用户接口层：
负责向用户展示数据和接收用户输入，根据不同的前端应用可以定制不同的数据适配器。（大白话：用户接口层以及各个不同种类的客户端）
2.应用层：
负责协调领域层多个聚合完成服务的组合和编排，不包含核心业务逻辑；（可以简单理解为服务模块层）
3.领域层：
负责实现核心业务逻辑，包含实体值对象聚合领域服务等概念
4.基础设施层：
负责提供通用的技术和基础服务，如数据库、缓存、消息中间件、三方服务等。

洋葱架构示例（画的有点丑，见谅
对于洋葱架构，本人只是举例这种画法本人不太喜欢仅供参考。）

这里一共分为四层
从内到外越往内部越稳定（箭头指向依赖关系）
实体层：
系统中的业务规则和领域模型，是架构中最核心稳定独立的层次。
用例层：
包含了系统中的应用逻辑和用例，依赖于实体层但不会依赖外层结构。
接口适配器：
包含了网关、接口、适配器等组件，负责将外部请求转换为内部用例，并将内部数据转换为外部格式。
架构和驱动设施层：
包含了前面的数据库、UI、web服务、技术框架等具体实现细节，也是经常需要改变和不稳定的层次结构。

PS：剩下的架构实在少见本人不太清楚画成什么样子所以就画两个俺学过的吧。