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