一、什么是领域驱动设计
1.1、面向业务的设计
当我们需要构建一个业务复杂的系统，我们不仅要从技术角度去构建一个稳健的系统，还要从业务角度出发，保证系统能满足业务需求。
架构设计的考虑点：不仅面向技术，更应该面向业务；面对不同的业务复杂度，选择的架构可能不同。
架构师的工作：面对复杂的业务逻辑，需要整合业务和技术才能很好地解决。业务架构驱动技术架构。
一个典型开发团队：新手、中级开发者、高级开发者/架构师（技术架构）、领域专家/产品经理（业务架构）、项目经理
要解决的问题：将复杂的业务架构梳理好，并能为技术架构的设计提供要求或指导。
总结：要进行一个业务复杂系统的架构设计，我们要将技术架构和业务架构整合起来。
1.2、使用领域驱动设计，让业务架构和技术架构能整合起来
既然业务对系统架构有影响，那么如何能将业务语言转化为对技术架构设计有指导意义的信息？
其中一种方法就是领域驱动设计。
领域驱动设计：Domain Driven Design（DDD），一种软件开发的方法学
什么是领域：一个组织的业务开展方式，体现业务价值。
例如：电商网站中的产品、订单、发票、库存、物流；保险公司的保险单、理赔、再保险等。
业务价值：有用的领域模型、抽象的业务定义、更好的用户体验、清晰的模型边界；目的是指导开发出优秀的技术架构。
如何使用DDD：
最终目标：能体现系统业务，又能指导代码开发的一个模型；将设计模型和代码模型很好地结合起来。
通用语言（Ubiquitous Language）：
- 团队成员的行话
- 面向业务
- 表现形式：术语表、文档和图、模型语言。。。
- 面临的挑战：领域专家持续不断介入、开发者对领域的思考方法
综上，我们可以考虑领域驱动设计的设计纬度，从2个方面来看领域驱动设计
设计的策略：
关注如何设计领域模型以及对领域模型的划分
- 领域/子域
- 通用语言
- 界限上下文
- 架构风格
用于清楚界分不同的系统和业务关注点
设计的技术：
关注技术实现的层面教会我们如何具体地实施DDD
- 实体/值对象
- 领域服务
- 领域事件
- 资源库
基于技术设计工具按照领域模型开发软件
总结：我们为使业务能指导架构开发，将业务架构与技术架构整合起来，提供的一种解决办法是领域驱动设计，并提出了领域驱动设计的实现策略和实现技术。
1.3、实现领域驱动设计的思路
- 提供一套通用的建模语言和术语
- 展示基于领域趋同的架构设计方法
- 展示实现领域驱动设计的各项关键技术
- 基于具体案例展示设计的策略和技术
二、领域与上下文
2.1、架构的轮回
领域（Domain）：
- 一个组织所做的事情以及其中所包含的一切内容
- 业务范围及所进行的活动
- 开发某个软件时，面对的就是组织的领域
领域模型（Domain Model）：
针对整个业务系统创建的模型
有2种建模方式：
单一、内聚、全功能式：现在不好
功能拆分、服务化、子域：现在越来越流行，如微服务
复杂系统的简单化：功能拆分
拆分关注点：核心功能、辅助功能、第三方功能
拆分后的功能组装：系统集成
功能拆分在领域驱动设计的表现：
拆分关注点：子域
功能组装：界限上下文
2.2、领域/子域/界限上下文
子域分类（一个常见分类）：
核心域：核心业务
支撑子域：专注于业务的某一方面
通用子域：用于整个业务系统
界限上下文：
领域存在于界限上下文中
每个模型概念、属性和操作，在边界之内有特殊含义
拆分上下文的策略：几个可以考虑的角度
根据业务/通用语言（合适）
根据技术架构（不建议）
根据开发任务分配（不建议）
一个团队一个上下文（合适）
2.3、我们的案例
项目计划系统
系统完成对某个项目任务的分解
系统的目的是项目计划的制定
计划的制定通过召开项目会议的方法进行
项目会议的与会人员需要确保身份的有效性
思路：
假想业务流程
围绕领域驱动设计的理念和实践
从策略的设计到技术的设计
层层剖析和演进
初步上下文拆分
