领域架构设计:从边界上下文到分层架构
在软件开发中,设计一个有效的架构是至关重要的。本文将深入探讨领域驱动设计(DDD)中的边界上下文、上下文映射、防腐层以及常见的支持架构,特别是分层架构。
边界上下文
在项目开始时,我们通常假设业务领域是不可分割的,并着手处理需求,以尽可能多地了解该领域并构建通用语言。随着项目的推进,我们会逐渐了解组织的运作方式、执行的流程、数据的使用方式以及事物的命名方式。
在大型组织中,同一个术语在不同人使用时可能有不同的含义,或者不同的术语表示相同的事物。这可能意味着我们跨越了子领域的无形边界,即原本认为不可分割的业务领域实际上由多个子领域组成。
在 DDD 中,问题空间中的子领域映射到解决方案空间中的边界上下文。边界上下文是应用程序中需要自己的通用语言和架构的区域,在这个区域内通用语言是一致的,并且边界上下文之间可以存在关系。
需要注意的是,子领域和边界上下文这两个概念有时看起来相似,容易混淆。可以通过理解领域和领域模型的区别来区分它们:领域代表要解决的问题,领域模型是实现问题解决方案的模型;同样,子领域是领域的一部分,边界上下文是解决方案的一部分。
发现上下文
以一个简单的预订系统为例,前端网站显然是一个子领域,但可能不是唯一的。该系统可能还需要一个后台管理面板来发布内容和提取统计信息,这可能构成另一个子领域。
在顶层架构的当前草案中,我们有两个候选的边界上下文。此时,有两个重要方面需要研究:每个边界上下文的边界以及它们之间的关系。
标记上下文的边界
将业务领域拆分为各个子领域,每个子领域代表一个可以用软