DDD介绍

WechatIMG341521705278_.pic_hd.jpg

这张图是2008年的银行信用卡的ER图，目前可以看到这图，图中的Entity的条目非常满当，非常拥挤，每一个Entity以及ValueObject由大量的属性构成。

WechatIMG351521705279_.pic_hd.jpg
到了2012年，当时的股票交易系统SOA(service oriented architecture)的架构，此时系统构图看着还是比较简洁的一种，但是到了后面就如下图所示了
WechatIMG361521705279_.pic_hd.jpg
2016年的股票交易系统，就变得异常的复杂了，想维护起来都是异常困难。
WechatIMG371521705280_.pic_hd.jpg
到了2018年，此时的保险项目的微服务架构形成了目前的形式。从上至下分别为API service， composition service， 以及core service ，从上至下，相当于从infrastructor慢慢形成组成API service，然后再有不同的API，组成相应的核心服务。
WechatIMG381521705280_.pic_hd.jpg
这样的架构属于数据驱动架构，这样做的目的主要是作为解耦。对于图中间的ESB，在之前的设计中可以理解为路由，比如一个请求入到ESB中，ESB会根据相应的数据，将请求导向相应的位置中去，图中左侧的web可以理解为每一个模块，这样一套ESB系统的投入差不多在千万级别左右，这样的系统适合用于分布式系统中，一般设置这种系统的规模，人数应该在400-500人左右才会设置这样的系统。
于此同时，在结合上面几个图，开始时候很简洁明了，到后面的及其复杂，因此我们考虑架构的时候应该把时间因素结合进去。
WechatIMG391521705281_.pic_hd.jpg

我们在架构的时候会遇到的问题

WechatIMG401521705282_.pic_hd.jpg

如何解决这个问题？
图中左侧的STORIES，可以理解为统一语言，在统一语言的基础的进行拆分，但是问题也随之出现，随着左侧的拆分，拆分粒度越细小，系统设计得越烂。
理想的架构思想应该是和进化论一样，随时时间的推移而进行演变，也就引导了下一步：适应度方程(Fitness Function)。

WechatIMG411521705282_.pic_hd.jpg

在图中，右侧的色彩块，每一个像素都代表着一种颜色，要让右边无规则的色彩慢慢演化成蒙娜丽莎这幅画，每一个色彩像素都会自动进行调整，往着蒙娜丽莎进行演化，这就是大致的适应度方程的介绍。更多关于适应度方程的介绍，可以上youtube。

WechatIMG421521705283_.pic_hd.jpg
架构与组织共同进化，这里的核心词是支撑域，核心域。一个团队的支撑域可能就是另一个团队的核心域，每一个团队最核心的任务就是找到属于自身的核心域。 WechatIMG431521705303_.pic.jpg
image.png

怎样适应进化论？使得架构更具生命力？Evan Bottcher提出一下概念，也就是这个圆形图案，要坚持四个原则

• fast feedback

• repeatability

• simplicity

• clean code

于此同时必须考虑到时间维度，将时间的考量纳入系统架构设计中。
并不是在业务领域的绝对正确以及规范就是代表着架构的正确。

同时在分解业务的时候，必须找到团队自身的核心域。
如何找到属于自己团队的核心域，这个得根据clients来具体分析，但是一定要关注时间维度。

WechatIMG441521705303_.pic.jpg WechatIMG451521705303_.pic.jpg

在现在的DDD中，一般情况是业务和系统捆绑在一起(??有点不理解这句话)。

WechatIMG461521705303_.pic.jpg

一般业务怎么落地？ 通常而言，对于目前情况，有两点

• common language

  
  WechatIMG511521705304_.pic.jpg

• boundary context

DDD构建快，建模快，但是不能盲目用在无限大的领域上。
根据梳理过后的需求，抽离出领域模型

一下均为实验项目

WechatIMG471521705303_.pic.jpg WechatIMG491521705304_.pic.jpg WechatIMG501521705304_.pic.jpg WechatIMG511521705304_.pic.jpg WechatIMG521521705314_.pic.jpg WechatIMG531521705314_.pic.jpg