领域驱动设计

模型

模型:对知识进行了选择性的简化和有意的结构化

  • 模型与设计相互影响
  • 模型是团队的通用语言
  • 模型是浓缩的知识

有效建模的要素

  • 模型与实现绑定
    • 如果模型不能帮助开发可运行的软件 那就毫无意义
    • 寻找一种可以绑定模型与程序设计的设计
  • 建立了基于模型的语言
  • 蕴含丰富的知识
  • 提炼模型
    • 不断对模型精简或者增加元素
  • 讨论

语言

领域模型可以作为一种语言

文档与图

文档不应重复表示代码已经明确表达的内容

领域

分层架构

批注 2020-07-21 125205

用户界面层(或表示层)

负责向用户显示信息和解释用户指令。这里指的用户可以是另一个计算机系统,不一定是使用用户界面的人

应用层

定义软件要完成的任务,并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大,也是与其他系统的应用层进行交互的必要渠道

应用层要尽量简单,不包含业务规则或者知识,而只为下一层中的领域对象协调任务,分配工作,使它们互相协作。它没有反映业务情况的状态,但是却可以具有另外一种状态,为用户或程序显示某个任务的进度

领域层(或模型层)

负责表达业务概念,业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的,但是反映业务情况的状态是由本层控制并且使用的。** 领域层是业务软件的核心 **

基础设施层

为上面各层提供通用的技术能力:为应用层传递消息,为领域层提供持久化机制,为用户界面层绘制屏幕组件,等等。基础设施层还能够通过架构框架来支持4个层次间的交互模式

软件中的模型

  • 关联

代表领域中两个实体的关联 以及技术里的关联

  • 实体 Entity

由标志所定义的对象

这个标识是什么?是一个ID

  • 值对象 Value Object

没有概念标识的对象

作为一个临时对象 通常用来传递消息

  • Service

有些操作是无法归类到某个值对象或者实体上面

需要使用Service来封装这些行为

  • 模块 Module

对一些职责类似的对象进行边界上下文封装

建模范式

  • 对象范式
  • 非对象范式
  • 混合范式

领域对象的生命周期

批注 2020-07-22 161447

  • Aggregate

Aggregate就是一组相关对象的集合,我们把它作为数据修改的单元。每个Aggregate都有一个根(root)和一个边界(boundary)。边界定义了Aggregate的内部都有什么。根则是Aggregate所包含的一个特定Entity。对Aggregate而言,外部对象只可以引用根,而边界内部的对象之间则可以互相引用

批注 2020-07-22 161748

  • Factory

当创建一个对象或创建整个Aggregate时,如果创建工作很复杂,或者暴露了过多的内部结构,则可以使用Factory进行封装。

创建方法要是原子的

工厂应该创建抽象类型 而不是具体类

  • Repositry

客户需要一种有效的方式来获取对已存在的领域对象的引用 Repository是一个简单的概念框架,它可用来封装对数据库的检索技术

对类型进行抽象

充分利用与客户端解耦的优点

将事务的控制权交给客户

重构

为实现更深层次模型而进行重构

突破

提炼概念

  • 有没有一些术语能够简洁地表达出复杂的概念
  • 借助领域专家 书籍
  • 不断尝试

隐式概念

  • 注意约束
    • Specification 模式就可以用来约束对象状态
  • 将过程提炼为领域对象

柔性设计

乐于使用 易于修改

  • 模式:Intention-Revealing Interfaces
    • 使用封装来解释代码的意图
  • 模式:Side-Effect-Free Function
    • 将操作粗略分为有副作用的命令以及无副作用的查询
  • 模式:Assertion
    • 声明前置条件与后置条件
  • 模式:Conceptual Contour
    • 概念轮廓 将设计元素组织成内聚的单元
  • 模式:Standalong Class
    • 类尽可能保持与其他类的低耦合 以此降低依赖带来的复杂度
  • 模式:Closure Of Operation 闭合操作
    • 入参类型与出参类型相同

声明式设计

把代码写成一种可执行的规则

也就说必须遵守某种预先定义好的规则

基于规则的编程

DSL

切入问题

分割子领域 尽可能利用已有的形式

战略设计

保持模型的完整性

看似相同的概念其实并不是同一个东西

  • 模式:Bounded Context
    • 限定模型的工作范围
  • 模式:Continuous Integration
    • 使用CI快速发现模型的错误
  • 模式:Context Map
    • 使用该模式描述两个边界上下文之间的关系

批注 2020-07-26 152329

  • 模式:Shared Kernel

批注 2020-07-26 152535

  • 模式:Customer/SupplierDevelopment Team
    • 建立上下游系统关系
  • 模式:Conformist
    • 使用承诺维护上下游系统关系
  • 模式:Anticorruption Layer
    • 封装遗留/外部系统

批注 2020-07-26 153136

  • 模式:Separate Way
    • 子系统分道扬镳 独立演化
    • 继承总是代价高昂 而且又是获益却很小
  • 模式:Open Host Service
    • 定义一套Service 暴露给其他系统
  • 模式:Published Language
    • 使用一种通用的语言作为通信媒介

精炼

  • 模式:Core Domain
    • 针对核心领域模型进行优化、开发
  • 模式:Gneric Subdomain
    • 降低非核心领域模型的优先级
  • 模式:Domain Vision Statement
    • 简短描述领域模型
  • 模式:Highlighted Core
    • 标记核心领域模型相关元素
  • 模式:Cohesive Mechanism
    • 当模型的某些行为变得复杂时 将这些行为抽离到一个独立的框架里
  • 模式:Segregated Core
    • 增强Core的内聚性
  • 模式:Abstract Core
    • 对核心领域进一步抽象 降低复杂度

大型结构

通过重构来得到这些结构

  • 模式:Evolving Order
    • 让结构随着代码一起演变
  • 模式:System Metaphor
    • 一种促进系统一致性的隐喻
  • 模式:Responsibility Layer
    • 注意系统中的依赖 根据依赖可能会形成自然的层次结构 进而进行抽取
  • 模式:Knowledge Level
    • 分层提高定制灵活度
  • 模式:Pluggable Component Framework
    • 设计一个可插拔的灵活框架

results matching " "

No results matching " "

results matching " "

No results matching " "