《领域驱动设计——精简版》随笔

基本构成要素:

通用分层:基础设施层、领域层、应用层、用户界面/展现层

1.实体
    包含一个唯一的标示符
2.值对象
    没有标示符
    值对象通常是不可变的对象
3.服务
    领域中的重要行为,但不能合并到实体或者值对象中
    应用服务和领域服务
    服务建立在领域实体和值对象的上层
4.模块
    模型越来越大,就要讲模型组织紧模块
    模块应该定义对外接口
    模块间仅有极少的连接会让人更容易理解系统如何工作
    设计人员习惯一开始就创建模块
5.聚合
    聚合是一个用来定义对象所有权和边界的领域模式
    每一个聚合都有一个根(实体),是外部可以访问的唯一对象
    不能将聚合的内部对象指针或者引用传递出去,只能传递内部对象的拷贝
6.工厂
    复杂的组装操作不是对象的创建过程
    工厂是违反对象封装原则的,因为对象的创建是他自身的职责
7.资源库
    资源库的目的是封装所有获取对象引用所需的逻辑
    资源库作为一个全局可访问的对象存储点存在
    资源库类似于基础设施,但其接口是完全的领域模型,所以处于领域层
    工厂关注的是对象的创建;资源库关注的是已存在的对象
    当一个新对象被添加入资源库时,他应该先由工厂创建过,然后传递给资源库

面向深层理解的重构

1.持续重构
    设计重构
    重构离不开自动化测试
    设计必须灵活,僵硬的设计很难做重构
2.凸显关键概念
    重构是小幅进行的,产生小的改进;很小的变更造成很大的改进,就是突破
    从一个粗糙的,肤浅的模型开始,然后基于对领域的深层理解以及对关注点的理解来细化它和设计
    让概念显示化时,有用的方法
    1)倾听话语
    2)使用领域文献
    3)约束:简单的表示不变量的方式
    4)过程:代码中表现为procedure;面向对象中,需要为过程选择一个对象,并为它添加行为;最好的方法是使用服务
    5)规约:用来测试一个对象是否满足特定条件的;规则被封装紧负责它的对象,这就成为了客户的规约,被保留在领域层
    
保持模型一致性

1.界定的上下文
    每个模型都有一个上下文
    模型应该足够小,以便能够分给一个团队去做
    主要思想是定义模型的范围,画出他的上下文的边界,然后尽最大的可能保持模型的一致性
    被界定的上下文不是模型,它提供了模型参与的逻辑框架。模块用来组织模型的要素,上下文包含模型
    不能在不同的模型间传递任何对象,也不能在没有边界的情况下自由的激活行为
    为每一个领域创建一个独立的模型
2.持续集成
    对小的团队,每日集成
3.上下文映射(Context Map)
    指抽象出不同界定上下文和他们之间关系的文档
4.上下文之间的高级交互模式
    共享内核(Shared Kernel):减少重复
    客户-供应商(Customer-Supplier):2个子系统之间的接口需要预先明确定义;2个团队之间确定明显的客户-供应商关系
5.让上下文高度独立和分开运行
    隔离通道(Separate Way)
6.系统和继承系统或者外部系统之间的交互
    开放主机服务(Open Host Service):当一个子系统要和许多子系统集成时,为每一个系统定制一个转换器回事整个团队陷入困境;定义一个能以服务的形式访问你子系统的协议,开放他,是所有需要和你集成的人都能获取到,然后优化和扩展这个协议
    防崩溃层(Anticorruption Layer):facade+Adaptor

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值