文章目录

1 面向领域思想
- 1.1 架构设计与领域驱动
- - 1.1.1 领域驱动设计
  - 1.1.2 使用领域驱动设计的条件
- 1.2 领域驱动设计核心概念
- - 1.2.1 策略维度
  - 1.2.2 技术维度
2. 面向领域的策略设计
- 2.1 通用语言
- 2.2 领域与上下文
- - 2.2.1 架构轮回
  - 2.2.2 系统拆分
  - - 子域
    - 界限上下文
    - 系统拆分策略
  - 2.2.3 上下文集成技术
  - - 避免大泥球风格
    - 组织关系
    - 集成模式
- 2.3 领域驱动的架构风格
- - 2.3.1 架构分层
  - - 领域驱动设计组件
    - 分包原则
    - 领域驱动设计组件与分包原则
    - 分层结构
  - 2.3.2 事件驱动架构
- 2.4 案例策略设计
- - 一 . 策略设计的思路
  - 二. 领域与上下文
  - - 子域的划分
    - 上下文
    - 架构风格

1 面向领域思想

与系统架构设计相关的有两种角色

负责技术架构的高级技术人员
负责业务架构的领域专家。

业务架构驱动技术架构，而不是技术架构驱动业务架构。

1.1 架构设计与领域驱动

1.1.1 领域驱动设计

概念：一种软件开发方法，强调开发人员与领域专家协作交付业务价值，强调把握业务的高层次方向，也强调系统建模工具和方法以满足技术需求。
核心：认为系统架构应该是业务架构和技术架构想结合的一种过程，并提供了一系列的设计相关工具和模式确保实现这一过程。

1.1.2 使用领域驱动设计的条件

以下问题，如果前两个为"是"，则系统本身并不具备复杂的业务逻辑。否则可使用领域驱动设计。

是否以数据为中心，所有操作通过对数据库CRUD实现？
是否只有少量用例，且每个用例只包含少量业务逻辑？
是否能预见到软件功能在未来会不断变化？
是否对软件所要处理的领域有足够了解？

1.2 领域驱动设计核心概念

在领域驱动设计中，有两个主要的设计维度

1.2.1 策略维度

设计的策略维度关注如何设计领域模型及对领域模型的划分，其目的在于清楚划分不同的系统与业务关注点。策略维度是一个面向业务、具备较高层次的的设计维度，偏重于业务架构的梳理及考虑如何把业务架构和技术架构相结合的问题。

1.2.2 技术维度

设计的技术维度关注技术实现，从技术的层面指导我们如何具体地实施领域驱动，关注基于技术设计工具按照领域模型开发软件。

2. 面向领域的策略设计

2.1 通用语言

也称为统一协作语言，思路是面向领域和业务，统一团队成员对领域知识的一致认识，促进后续代码模型中的命名等使用领域词汇而不是技术词汇。

2.2 领域与上下文

2.2.1 架构轮回

如图，系统从简单到复杂，以至于不可维护，就需要重构拆分，这便是架构的轮回：

2.2.2 系统拆分

子域

核心域：系统中的核心业务
支撑子域：专注于业务的某一方面的子域
通用子域：可以用于整个业务系统且作为一种基础设施的功能

界限上下文

概念
子域存在于界限上下文中。这里的界限指的是每个模型概念、属性和操作，在特定边界之内具有特定的含义。这些含义只限于该界限之内。
示例
整合子域与界限上下文的示例结构如图

说明：
该图根据业务功能的特性把整个系统拆分成4个主要的子域，分别包含一个核心子域、两个支撑性子域及一个通用子域。每个子域都有其界限上下文，各个界限上下文之间可以根据需要有效整合从而构成完整的领域。

系统拆分策略

根据业务和通用语言进行系统拆分（推荐）
技术架构拆分系统（不推荐）

违背了业务架构驱动技术架构的原则，在对业务梳理尚不完善、系统的策略设计尚不健全的情况下就考虑技术架构和实现方法，往往会导致返工，在不断的系统修改中腐化架构。

根据开发任务拆分（不推荐）
一个团队一个上下文

一种跨职能（Cross Function）的团队构建方式，团队中包括服务端、前端等各种角色。

2.2.3 上下文集成技术

避免大泥球风格

大泥球风格
系统架构的演进和腐化结果的表现之一就是形成一种所谓的大泥球风格（Big Ball of Mud）。其特点是边界模糊、没有清晰的结构。

虽然大泥球是一个反设计、具有讽刺意味的词语，但仍然是最常见的软件设计表现形式。

组织关系

供应商关系：
客户方依赖供应商提供的服务才能构建自身的系统。
供应商关系是主流但不是最好的组织关系，因为处于下游的客户方系统受处于上游的供应商影响巨大。
合作关系：
分别处于上游和下游的两个上下文团队共同进退，双方通过制定合理的开发计划确保上下文集成工作能够顺利开展。
合作关系是比较理想的关系，尽管并不一定能够有类似的条件。
遵奉者关系：（应避免）
上游由于利益关系等因素并不想或没有能力推动系统集成，那下游只能妥协或另谋他路。

集成模式

系统集成模式的基本思路在解耦和统一。因此抽象出两种基本的集成模式：

防腐层（Anticorruption Layer，Ac L）

防腐层强调下游上下文根据领域模型创建单独一层。该层完成与上游上下文之间的交互，从而隔离业务逻辑，实现解耦。

统一协议（Unified Protocol，UP）。

统一协议则是提供一致的协议定义，促使其他上下文通过协议访问。

2.3 领域驱动的架构风格

2.3.1 架构分层

领域驱动设计组件

领域组件
包含对领域、子域、界限上下文等策略设计相关内容，也包含后续所要阐述的所有技术设计组件。领域组件代表抽象模型，并不包含具体实现细节和技术。
基础设施组件
领域组件中的部分抽象接口需要通过基础设施提供的服务得以实现，所以基础设施组件对领域组件存在依赖关系。

比如，数据相关操作对于领域模型而言只是持久化的一种抽象，不应该关联具体的实现方式，这些数据访问的实现可以统一放在基础设施组件中，也就是说基础设施组件实现了领域组件中的抽象接口。

应用组件
应用组件面向用户接口组件，是系统对领域组件和基础设施组件封装。
用户接口组件
用户接口处于系统的顶层，直接面向前端应用，调用应用组件提供的应用级别入口完成用户操作。

分包原则

无环依赖原则
在组件的依赖关系中不能出现环路

我们可以通过上移、下移、回调等手段打破循环依赖。

稳定依赖原则 （Stable Dependencies Principle，SDP）

认为被依赖者应该比依赖者更稳定，也就是说如果包B还不如包A稳定的话，就不应该让包A依赖包B。

稳定抽象原则（Stable Abstractions Principle，SAP）
- 一个稳定的组件应该也是抽象的。这样它的稳定性就不会无法扩展
- 一个不稳定的组件应该是具体的，因为它的不稳定性使其内部代码更易于修改
依赖倒置原则（Dependency Inversion Principle DIP）
- 高层不应该依赖于底层，两者都应该依赖于抽象
- 抽象不应该依赖于细节，细节应该依赖于抽象

领域驱动设计组件与分包原则

领域组件
应是抽象且稳定的，也就是说它应该位于系统分层的底端被其他组件所依赖。
用户接口组件
通常是最不稳定的，应处于系统的顶层
应用组件
处于用户接口组件和领域层之间
基础设施组件

分层结构

分层架构
平面形架构

2.3.2 事件驱动架构

事件驱动作为一种典型的架构风格同样包含在领域驱动设计过程中，并应用于上下文集成的解耦。

上图说明：
领域事件由事件源生成，并通过事件发布器进行发布，各种事件的订阅方根据需要进行订阅。订阅方根据自身需求可以直接处理该事件，自身不能处理可以即时转发给其他订阅方，事件作为一种业务数据的载体，也可以进行存储以便后续处理。

2.4 案例策略设计

一 . 策略设计的思路

当我们面对有限的系统需求信息，基本思路是根据以下问题找到合适的答案。

核心域的通用语言

找到系统的核心域，并根据核心域的定位和作用梳理其通用语言。核心域的通用语言包括该子域的名称及基本需求约束。

核心域的支撑子域和通用子域

有了核心域，下一步就是判断系统是否只要一个核心域就能满足建模需求。如果不是，那就要判断是否需要相应的支撑子域和通用子域。支撑子域和通用子域不一定都需要，但有时候系统也会存在多个支撑子域或通用子域。

核心域与其他子域的协作和集成

系统的交互和集成以核心域为主体展开。当核心域面对支撑子域或通用子域时，使用的协作和集成策略往往是不一样的。这方面需要根据具体的子域进行分析和设计。

针对各个子域安排人员

二. 领域与上下文

子域的划分

首先提取项目核心域作为系统的核心域。
计划讨论域是系统的支撑子域，专注于通过讨论得出项目计划之一业务需求；
验证用户有效性的功能可以单独提取一个用户中心域（项目会议与会人员需要确保身份的有效性）。显然系统的用户管理是一项基础性功能，可能会面向其他系统，所以最合适作为一个通用子域进行维护。

上下文

子域的关系图
子域的交互时序图

架构风格

案例的架构风格基本可以沿用通用的领域驱动架构风格，平面形架构和事件驱动架构构成了案例系统架构设计的基本组成。对于三大子域之间的界限上下文，我们可以抽象出一批端点和适配器。对于每种界限类型，都有一套端口和适配器与之相对应，确保内部领域模型不会泄露到外部系统。而具体使用基于HTTP的RESTful亦或消息传递系统等方式进行各个界限上下文之间的集成实现，我们将在面向领域的技术设计中具体展开讨论。

《系统架构设计》-06-面向领域思想和策略设计相关推荐

软考高级系统架构设计师：特定领域软件架构
软考高级系统架构设计师:特定领域软件架构一.4+1视图二.软件系统在特定领域重用DSSA 三.特定领域软件架构创建步骤 1.定义领域范围 2.定义领域特定元素 3.定义领域特定的设计和实现需求约束 ...
软考·系统架构师论文——论软件的高并发设计
文章目录说明摘要过渡项目背景论点理论论点实践结尾说明 1.[摘要 300~330字] ① 项目介绍:时间.项目名.项目主要功能简述.作者角色及工作内容 ② 项目技术简介:正文理论/分论 ...
系统架构设计师考试题库重点案例：软件架构设计与评估（效用树）
题: 某单位为了建设健全的公路桥梁养护管理档案,拟开发一套公路桥梁在线管理系统.在系统的需求分析与架构设计阶段,用户提出的需求.质量属性描述和架构特性如下: (a) 系统用户分为高级管理员.数据管理员 ...
[架构之路-127]-《软考-系统架构设计师》-计算机网络 -1- 协议栈、网络规划与设计、网络接入技术
前言: 第1章 TCP/IP协议族 1.1 计算机网络概述计算机网络是计算机技术和通信技术相结合的产物.计算机网络是信息收集.分发.存储.处理和消费的重要载体. "计算机网络"这 ...
【系统架构理论】一篇文章搞掂：领域驱动设计
一.什么是领域驱动设计 1.1.面向业务的设计当我们需要构建一个业务复杂的系统,我们不仅要从技术角度去构建一个稳健的系统,还要从业务角度出发,保证系统能满足业务需求. 架构设计的考虑点:不仅面向技术 ...
十全干货：核心游戏系统架构设计
http://www.gameres.com/677342.html 文/AI分享站Finney 首先先来定义一下什么是我这里说的核心游戏系统,一般来说,游戏可以大致分为两个部分,一个部分是我这里指的 ...
实践出真知：全网最强秒杀系统架构解密！！
很多小伙伴反馈说,高并发专题学了那么久,但是,在真正做项目时,仍然不知道如何下手处理高并发业务场景!甚至很多小伙伴仍然停留在只是简单的提供接口(CRUD)阶段,不知道学习的并发知识如何运用到实际项目中 ...
看了这个高并发系统架构，才知道我对秒杀的误解有多深
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取推荐书籍来源:33h.co/dCNy 很多小伙伴反馈说,高并发学了那么久, ...
Linux系统——架构浅析
导语:掐指一算自己从研究生开始投入到Linux的海洋也有几年的时间,即便如此依然对其各种功能模块一知半解.无数次看了Linux内核的技术文章后一头雾水,为了更系统地更有方法的学Linux,特此记录. ...

《系统架构设计》-06-面向领域思想和策略设计