DDD-第五课

第五课-微服务规划:以领域为中心规划服务

image-20200808211545634

架构反应了重要的决策:

架构定义了系统在其环境中的基本概念或特性,体现在其元素、关系以及其设计和演化的原则。

Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its dedign and evolution.

——ISO/IEC 42010:Systems and software engineering

——Architecture description

技术演进降低决策难度,聚焦于解决真正的问题

image-20200808213249079

本讲大纲:

1.子域和限界上下文,从问题域出发分而治之;

2.微服务带来了真正的边界;

3.上下文映射、API接口和设计契约。

image-20200808213856766

软件的复杂性和关注点分离

image-20200808214249268

分而治之在解决复杂问题的同时带来更大价值:

1.各个击破;

2.独立进化;

3.易于复用。

image-20200808214532679

以领域为核心——领域和子域

避免过大的领域模型。用一套模型来描述整个软件系统并不现实

1.简化认知——人并不能同时记住太多概念,刻意地忽略;

2.隔离变化——分而治之,每次处理一个特定方面,隐藏无关信息;

3.聚焦重点——区分那些对业务最重要的因素和次要的因素。

DDD中的相关模式

1.核心域:简化模型。定义一个核心域,并将其与大量支持模型和代码区分开来。

提炼核心域中最有价值和最专业的概念,把核心变小;

将顶尖人才分配到核心域中;

把精力花在核心域上,发现深层模型,确保获得足以实现系统愿景的灵活设计。

2.通用子域:识别那些非核心的领域。

分离通用子域,并把它们放在单独的模块中;

不要让通用子域包含核心域的知识;

考虑分离通用子域的开发人员,最好是使用既有的解决方案。

3.领域愿景陈述:明确核心领域的价值主张。

篇幅不要超过一页;

价值主张需要明确——只提现本领域模型和其他领域具有显著差异化的方面;

尽早完成,并在产生新的洞解时及时解决。

image-20200808215558794

如何拆分子域?

最重要的原则:领域体现的是业务能力

1.能不能用一句话说清目标?

2.是不是有一组内聚的核心概念?

3.有没有可能成为一项独立的业务?

启发式原则:

1.观察业务流程;

2.观察领域模型;

3.观察分析过程。

在业务流程中识别领域

image-20200808215858392

image-20200808220033360

image-20200808220053381

image-20200808220110863

image-20200808220127259

在领域模型中识别领域

image-20200808220222829

image-20200808220336158

演进纬度

image-20200808220654942

领域和子域拆分的要点总结:

1.分而治之是复杂性管理的基本方法,而且有助于隔离变化,提升复用;

2.领域的划分应该从业务视角出发,而不是实现视角;

3.在业务流程分析和领域模型中自然地分解,并保持持续演化的心智;

4.区分核心域和通用域,并在核心域上进行重点投资。

限界上下文(Bounded Context):最好的工作边界和问题域一致的边界。

限界上线问是什么:限界上下文是一个显式的边界。

image-20200808221338866

限界上下文和子域

观点:如果你在构建全新的系统,请让限界上下文的边界和子域定义保持一致。

image-20200808221547214

用领域模型和统一语言抵御破坏边界的冲动:

障碍1:环境——认知不足和习惯思维;

障碍2:外部——客户压力;

障碍3:自身——缺乏抽象习惯,不注意关注点分离;

不正确的实现破坏了领域边界:

image-20200808222034948

point:评论获得的积分;

isAdminMessage:是否管理员的回复;

memberService:与point是一样的问题。

微服务带来了真正的边界

微服务是一种架构风格

image-20200808222400345

微服务和 子域/限界上下文 紧密相关

image-20200808222445557

以服务的方式实现组件化

image-20200808222551562

image-20200808222718357

围绕业务能力进行组织:

image-20200808222841695

子域和服务规划:以领域作为核心关注点,兼顾非功能性需求,保持持续演化

image-20200808223122703

服务是一种组件化方式

image-20200808223534541

微服务和限界上下文彼此呼应:

1.领域需要一个边界(限界上下文);

2.微服务带来了真正的边界;

3.领域需要具有明显的业务价值,并保持持续生长;

4.微服务倡导围绕着业务价值构建服务和团队;

5.在领域层使用领域模型指导服务划分。并不需要为每个构造块定义一个服务,但是构造块提供了服务拆分的良好参考。

上下文映射、API接口和设计契约

上下文映射

image-20200808224325524

共享带来耦合,转化带来损失。

上下文映射的模式:

image-20200808224413604

image-20200808224503653

image-20200808224741892

观点:

如果提供方接口变化带来了问题,但是消费方未能发现,是消费方的责任。

image-20200808225401468

客户供应商:

1.依赖方(可以有多个)是被依赖的客户;

2.依赖方和被依赖方共同开发自动化验收测试,并且加入到被依赖的测试套件中;

3.非常适用于被依赖方的领域模型需要探索的情况。

防腐层ACL

被依赖方对依赖方没有承诺;

被依赖方的领域模型质量不好,或者不符合依赖方的需求,或者依赖方不想和被依赖方捆绑在一起

image-20200808225720110

事件机制和上下文映射

事件是解耦业务领域的非常关键的方法

image-20200808225825200

image-20200808225907889

image-20200808230111909