DDD学习笔记 - 基础篇（Ⅰ）

最近在自学DDD（领域驱动设计），打算将学习笔记以博客的形式记录下来。

---------------------------------------------------------------------------------------------------------------------------

领域驱动设计DDD

 

开篇词

作为中台，需要将通用的可复用的业务能力沉淀到中台业务模型，实现企业级能力复用。

早在2003年就诞生的DDD，怎么来指导迟到近20年才大热的微服务设计呢？

 

1.搞清楚DDD的核心设计思想，DDD、微服务和中台的关系：

中台本质是业务模型，微服务是业务模型的系统落地方案，DDD是一种设计思想，它可以同时指导中台业务建模和微服务设计，他们之间是铁三角关系。

DDD强调领域模型和微服务设计的一体性，现有领域模型然后才有微服务。

 

2.战略设计。建立领域模型、划分为服务边界。关键

 

3.战术设计。从领域模型转向微服务设计和落地。

 

术语多且陌生。

DDD必知必会十大概念、微服务架构分层、代码模型设计、DDD战略设计、事件风暴、领域建模、企业级中台业务建模。走一遍DDD战略设计和战术设计的全流程，DDD在领域模型和微服务设计过程中的技术要点。深化微服务设计原则、建立演进式微服务架构。

 

基础篇：领域、子域、核心域、通用域、支撑域、限界上下文、实体、值对象、聚合、聚合根。

 

进阶篇：领域事件、DDD分层架构、常见的微服务架构模型、中台设计思想

• 如何通过领域事件实现微服务解耦
• 怎样进行微服务分层设计
• 如何实现层与层之间的服务协作
• 领域模型和微服务分层的作用和价值
• 中台设计的核心思想，如何实现前中后台的协同和融合，如何利用DDD进行中台设计

 

实战篇：中台和领域建模的实战、微服务设计实战

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

 

01 | 领域驱动设计：微服务设计为什么要选择DDD？

课程链接：https://time.geekbang.org/column/article/149943

微服务设计过程中往往会面临边界如何划定的问题，微服务到底应该拆多小？

 

软件架构模式的演进：

大体来说经历了单机、集中式、到分布式微服务架构三个阶段。

 

单机架构：采用面向过程的设计方法。系统包括UI层和数据库两层，采用C/S架构模式，整个系统围绕数据库驱动设计和开发，总是从设计数据库和字段开始。

集中式架构：采用面向对象的设计方法，包括业务接入层、逻辑层和数据库层，是经典的三层架构，也有的采用传统的SOA架构。这种架构容易是系统变得臃肿，可扩展性和弹性伸缩性差。

分布式微服务架构：随着微服务架构理念的提出，集中式架构正式向微服务架构演进。可以很好的实现应用之间的解耦，解决单体应用扩展性和弹性伸缩能力不足的问题。

 

在单机和集中式架