这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天

新年第二课 架构初探

核心

代码架构就是详细设计中的核心内容!

作用

代码架构承上启下,决定软件质量

• 承上 说明业务逻辑和业务领域模型
• 本身 保证代码有更好的可读性和可维护性、可扩展性
• 启下 承载代码运行的硬件部署架构

DDD

DDD（Domain Driven Design，领域驱动设计）作为一种软件开发方法，它可以帮助我们设计高质量的软件模型。在正确实现的情况下，我们通过DDD完成的设计恰恰就是软件的工作方式。

UL（Ubiquitous Language，通用语言）是团队共享的语言，是DDD中最具威力的特性之一。不管你在团队中的角色如何，只要你是团队的一员，你都将使用UL。由于UL的重要性，所以需要让每个概念在各自的上下文中是清晰无歧义的，于是DDD在战略设计上提出了模式BC（Bounded Context，限界上下文）。UL和BC同时构成了DDD的两大支柱，并且它们是相辅相成的，即UL都有其确定的上下文含义，而BC中的每个概念都有唯一的含义。

一个业务领域划分成若干个BC，它们之间通过Context Map进行集成。BC是一个显式的边界，领域模型便存在于这个边界之内。领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。

从广义上来讲，领域即是一个组织所做的事情以及其中所包含的一切，表示整个业务系统。 由于“领域模型”包含了“领域”这个词，我们可能会认为应该为整个业务系统创建一个单一的、内聚的和全功能式的模型。然而，这并不是我们使用DDD的目标。正好相反，领域模型存在于BC内。 在微服务架构实践中，人们大量地使用了DDD中的概念和技术：

微服务中应该首先建立UL，然后再讨论领域模型。 一个微服务最大不要超过一个BC，否则微服务内会存在有歧义的领域概念。 一个微服务最小不要小于一个聚合，否则会引入分布式事务的复杂度。 微服务的划分过程类似于BC的划分过程，每个微服务都有一个领域模型。 微服务间的集成可以通过Context Map来完成，比如ACL（Anticorruption Layer，防腐层）。 微服务间最好采用Domain Event（领域事件）来进行交互，使得微服务可以保持松耦合。 .