DDD领域驱动设计
传统运维实质上是补补丁，会使系统越来越复杂，性能下降，耦合高。
DDD则是从整体结构上解决业务变更带来的问题。详见对象划分原则
待解决问题
Day1.DDD的作用和意义
使用要求：
系统变得越复杂时适合使用
当程序简单时反而不适合。
作用域：作用和意义
- 最初的项目：为了日后维护变更时的方便
- 不断维护的项目：方便完成业务升级
- 未来的项目：业务越来越复杂、技术更新速度快、系统变得庞大、市场激烈竞争。
架构演变。
此时业务和框架耦合在了一起。采用整洁架构，有一个中间接口层进行两者解耦。使其完成更新。
DDD过程：
1领域建模：深刻理解业务，转换成领域模型。
2.领域建模装换成数据库设计
3.领域建模转换为充血模型再到贫血模型
DDD解决之道
领域建模+微服务设计来完成越来越复杂的架构设计。
缺点：会增加复杂度，降低交互速度。
解决缺点：整洁架构设计
小而专的微服务设计
某几个微服务都需要调用同一个表时会导致服务被影响。
如购物、交易、配送服务操作商品表的情况。
应当设计成某个表只让一个微服务进行操作，对其他服务提供调用接口完成调用。
跨库关联查询解决方案
从原来的将两个表join起来完成查询变成先查询订单后补填用户。自己补填的话需要花费大量时间设计一个底层来在查询完订单信息后自动补填用户信息。以此来更多的关注于业务。
2.How to DDD？
软件规模化给团队带来的挑战
频繁的变更导致软件质量的下降。于是软件的维护越来越难，因此软件的架构极为重要！
由简单------>复杂
原来的做法是直接在padoff方法中不断添加代码导致越来越难以维护。现在应该调整程序结构。
领域建模思想
调整程序结构的方法即 领域建模思想
对象应与现实世界事物相对应。
方法与现实世界行为对应。
关联与现实世界相对应。
单一职责原则SRP
理解：即对象划分原则
软件系统中的每个元素只完成自己职责内的事情，将其他的事情交给别人去做。
“职责”通常理解，与其相关的事情都是它的职责。错误理解
“职责”正确的认知：一个职责是软件变化的一个原因 原因！！！
帮助理解：即设计为 更改这一需求时不牵扯别的需求，类似于微服务的拆分。
以前自己的理解：拆分的不够专，导致耦合较高。
案例：
如付款时添加折扣功能：
领域模型
设计实现
限界上下文？
真实世界中场景是多样化的
折扣、支付、等
故领域建模图应当为多个小的图而不是一张大的图
案例
远程智慧医疗系统
初期：传统的诊所管理系统
统一语言建模与领域建模
- 事件风暴
-
事件即事实
领域事件：命名都是过去式，且事情很重要，有记录。
且需要识别领域事件有无聚合
eg：
需要识别领域事件有无聚合
删除了整体后部分也会消失 -
事件风暴会议
目标：进行领域建模
领域建模
限界上下文
自我总结：活动者单独划分，功能模块依次划分。
-