领域驱动设计开篇之_2_领取驱动设计概览
前言
Github：https://github.com/HealerJean
一、介绍
应对软件复杂度的调整，大概是构建软件过程中唯一亘古不变的主题，而能够应对软件复杂度的只能是设计方法，原因是我们无法控制客观存在的问题空间，但是我们可以改变设计的质量，让好的设计为控制复杂度创作了更得机会， 那么如果说 要想克服（业务系统）软件的复杂度，就需要非常严格的使用领域逻辑设计方法，一种有效的领域逻辑方法就是 领域驱动设计
问题1：领域驱动设计是怎么样应对软件复杂度的呢？
答案：领域驱动设计是一种思维方式，影响如在读的3个因素：规模、结构、变化。控制复杂度的着力点就在这3个方面，领域驱动设计对软件复杂度的应对，是引入了一套提炼为模式的数据元模型，对业务软件系统做到了对规模的控制，结构的清晰，以及对变化的响应
二、领域驱动基本概念
1、问题空间和解空间
软件世界可以一分为二，分为构建世界的真实时间和获取解决方案的理想世界。再软件构建过程中，就是从真实世界映射到理想世界的过程。 软件系统的构建其实就是对问题空间的求解，获得构成解空间的设计方案
2、战略设计和战术设计
1）战略设计阶段
战略设计阶段需要从以下2个方面考量
问题空间：对问题空间进行合理分解，识别出核心子领域，通用子领域和支持子领域。并确定出各个子领域的目标、边界和建模战略
解空间：对问题空间进行解决方案的架构映射，通过划分界限上下文， 为统一语言提供语境，并在其边界维护领域模型的统一，每个界限上下文的内部都有自己的架构
2）战术设计阶段
战术设计阶段需要在界限上下文内部开展领域建模，前提是你为界限上下文选择了领域模型，在界限上下文内部，需要通过分层架构将领域独立出来。
三、控制软件的复杂度
1、控制规模
问题空间的规模客观存在，除了在软件构建过程中通过降低客户的期望，要在问题空间控制规模，我们手上的筹码不多，但是如果到了解空间，开发人员就能掌握主动权了。这个时候虽然不能控制系统的规模，但是我们却可以分而治之。将一个庞大的系统持续分分解为小的元素。当然这种分解不是无原则的拆分，在拆分的同时要保证被分解的部分能够合并成一个整体。
问题1：分而治之是一个好方法，但是怎么个分法呢？
答案：领取驱动设计提出了两个重要的设计元模型，界限上下文和和上下文映射。他们是控制系统规模最有效的手段。
1）样例：如果通过界限上下文控制系统的规模
a、功能：
国际报税系统是为跨国公司的驻外出差雇员（系统中被称之为 Assignee）提供方便一体化的税收信息填报平台。客户是一家会计师事务所，该事务所的专员（Admin）通过该平台可以收集雇员提交的报税信息，然后对这些信息进行税务评审。如果 Admin 评审出信息有问题，则返回给 Assignee 重新修改和填报。一旦信息确认无误，则进行税收分析和计算，并获得最终的税务报告提交给当地政府以及雇员本人。
系统涉及功能：
- 驻外出差雇员的薪酬与福利
- 税收计划与合规评审
- 对税收评审的分配管理
- 税收策略设计与评审
- 对驻外出差雇员的税收合规评审
- 全球的 Visa 服务
角色：
- Assignee：驻外出差雇员
- Admin：税务专员
- Client：出差雇员的雇主
b、采用领域驱动设计后
采用领域驱动设计，我们将架构主要关注点放在了领域，通过分析客户需求以及现在的问题问题空间，在解空间利用界限上下文对系统进行分解后，获得的界限上下文如下
每个限界上下文都是一个独立的自治单元。根据限界上下文的边界划分团队，建立单独的代码库。团队只为所属限界上下文负责：除了需要了解限界上下文之间的协作接口，以确定上下文映射的模式，团队只需要了解边界内的领域知识，为其建立各自的领域模型。系统复杂度通过限界上下文的分解得到了明显的控制。
2、清晰结构
保持系统结构的清晰是控制结构复杂度的不二法门，关键在于，要以正确的方式认清系统内部的边界，接下上下文从业务能力从业务能力角度形成了清晰的边界。它与业务模块不同，在内部也有独立的架构。通过分层架构将领域分离出来，在业务逻辑与技术实现之间划定一条清晰的边界
1）业务复杂度和技术复杂度
业务需求带来的复杂度称为 业务复杂度，质量需求带来的复杂度称为 技术复杂度
业务复杂度 和 技术复杂度 并非完全独立，二者相互作用会让系统的复杂度变得不可以预测。要避免业务逻辑的复杂度和技术实现的复杂度混杂在一起，就需要确定业务逻辑与技术实现的边界，从而隔离各自的复杂度，
领取驱动设计 引入的 分层架构 规定了严格的分层定义，将业务逻辑封装在领域层，将支撑业务逻辑的技术实现封装在基础设施层，
3、响应变化
4、冷静认识
控制软件复杂度是构建软件过程中永恒的旋律，必须明确：软件复杂度可以控制，但不可消除
