在理解域、子域、限界上下文、模块等之间的差异时遇到过困难？
问题
在问题空间中，也就是我们需要解决的问题中：
- Domain领域（例如，酒店）
- 子域（例如，“预订”、“住宿”）。
领域包含知识以及我们想要解决的一组问题。
解决办法
当我们深入研究解决方案空间以使用软件解决这些问题时，经常将每个子域映射到有界上下文BC。
有界/界限上下文 (BC) 是我们定义的一个区域，用于通过清晰的领域模型和语言来解决特定问题（对于子域），以及所有必要的软件组件（代码、数据库、消息传递等）。
业务上下文环境可以是分散的，分布在软件的各个部分（通常被描述为“旧的整体”或“大泥球”），但有界上下文BC不应该这样。
领域驱动设计的贡献是：
- 将这些业务上下文划分为软件中连贯且一致的有边界的、划分了界限的区域（通常被描述为"土豆potatoes"，但后来被隔离为模块、服务等）。
- 并使用领域人员的语言作为指导来识别这些区域。
然后，我们需要考虑如何将它们连接在一起，以防我们需要涉及其他BC来解决用户的问题（战略DDD提供了一套实现该目标的模式）。
有界上下文（及其关系）之间关系称为上下文映射。
什么是用户端应用？
在终端用户应用程序方面，您可以拥有只针对一个小的子域的小型应用程序（尽管这种情况很少见），或者更有可能拥有涵盖多个主题、多个子域（在某些情况下甚至是多个域）的应用程序。
在多个子域的情况下，我们必须在同一个面向最终用户的展示区（即应用程序）中组成和装配多个 Bounded Context。
当涉及到Web应用程序时，这些组装/拼凑代码将被划分为前端代码（在Web浏览器中执行）和后端代码（在服务器上执行）。
关于后端代码，它可以是：
- 模块化整体"，即在同一个可执行文件中托管多个模块（可理解为多个BC），它们通过方法调用（in-proc）相互通信。
- 通过网络调用（out-proc）与其他外部（微/宏）服务通信的模块
用户端的应用使用BC有意义吗？
我们是否应该将应用代码中的BC组合视为一个单独的 "应用 "BC（如果是，我们应该将其关联到哪个业务领域，应该给它起什么名字？
banq注：如果将后端BC在前端合并在一起，其实代表BC没有划分清楚，这是模块化单体的最大缺点，因为人作为主语上帝，是位于业务代码之上，可以任意跨上下文胡乱调用，只有将人分配进入不同微服务团队，通过微服务能彻底杜绝这种现象，因为不同BC是不同微服务团队开发，如果你是所在的微服务团队的前端，需要整合其他微服务团队的BC，你需要发起开会沟通，这已经触发警报了。