这两天把《dddquickly》这本书基本读完了,讲一下我自己的一些体会,肯定会有很多疏漏,不过没关系,反正我之前连写读后感的勇气都没有,现在能写也是勇气可嘉.
DDD主要是一种设计思想,它不是像设计模式那样怎样组织代码会更好,而是很像SOLID五大设计原则那样,会知道你这么写代码是不对的,DDD设计的软件会用到设计模式,比如工厂,资源库.当涉及到模块之间通信,防止代码腐败时候,可能还会用到门面等
它的架构分四层:
1、User Interface 用户接口层,这一层对应我们的Controller层,是供调用方调用的
2、Application 这一层是应用层,这一层其实没太懂,我想可能是由于跟我的经历有关,之前都是接触的单体应用有关把
3、Domain 这一层是我们主要关注的领域层,因为其它层建立好了基本不太会轻易变化
4、Infra 这一层是基础服务层,主要给我们提供基础服务,比如日志、Http Client、全局异常的捕获、消息队列等等
DDD是主要围绕问题域来进行产品设计、开发,讲究的是对产品的深度理解,通过对领域知识的不断扩充,再进一步对模型进行改进,这里的模型改进意味着设计、代码都会进行相应的变更,这里有两个重要的角色,一个是开发,另一个是领域专家,领域专家不见得就是产品经历,而是对这个相关业务最了解的人,双方需要通过“通用语言”来进行产品沟通,通用语言是经过双方协商之后,大家都能理解的领域知识
确定了模型、提炼出通用语言之后,就需要对模型进行设计了,这里的设计其实主要是代码层面的,代码设计是对模型的完全映射,模型中需要确定以下几个东西:
1、Entity 实体 有确定身份的唯一标识的东西就是实体,这里的唯一标识可以是一个,比如身份证号码,也可以是多个,比如姓名、门牌号、性别这三个
2、ValueObject 值对象 并不需要唯一标识的东西,比如用户的常用信息: 性别、所在城市等等这些
3、Service 服务 不能用实体或值对象来表示,并且还会有一些行为,而且这些行为都是跟领域相关的,这种情况就叫做服务
4、模块 是对于一个大的领域的细化的拆分 (画外音: 这里其实我也很模糊)
4、聚合根 对于一个领域中很可能会有多个实体、值对象,而对外暴露的只有聚合根、聚合根是对多个实体或值对象的创建过程的封装
5、工厂 是对多个聚合根的封装
6、资源库 它是对工厂生产对象的一个数据封装,而且它还可以有一些策略方面的设置,比如对哪些需求展示哪些数据等
产品上线后要不断的对代码进重构,当然是基于模型的重构,对于需要跟老代码进行通信的需求,需要引入限界上下文 (Bounded Context),这里我没看懂,所以也就不再赘述