问业务服务应该跨越有界的上下文吗？

EN

您可能刚刚确定了对一个函数的需求，它不是特定于任何一个部门，而是形成了一种基本的基础结构。考虑形成一个有限制的上下文“基本基础设施”，并在那里分配文档服务。这样，不同的上下文之间就有明确的边界和依赖关系。基本文档服务仍然可以被任何部门使用，而不会影响您的设计。

考虑在更通用的文档服务之上的特定实现，以处理特定于某个部门的功能(或者更确切地说:业务功能)。然后，这些特定的实现将属于各自的有界上下文。例如。

• 基本基础设施:GenericDocumentationService(文档，属性)-其中文档是要存储的文档，属性是键/值巴黎的列表
• 客户咨询:ConsultancyDocumentationService(文件，客户)
• 健康与安全:HealthSafetyDocumentationService(文件、风险、缓解)

例如，客户端和健康与安全实现将验证和处理它们的特定参数，然后使用通用服务来最终存储文档。

注:一般情况下，部门等业务组织结构并不能形成良好的界限。理由:组织结构往往会随着时间的推移而改变，这种变化很可能会使先前确定的边界失效。相反，最好确定核心业务功能，并将这些功能分组到逻辑上具有凝聚力的块中。

您的文档信息服务没有理由不能被设计成存储在其中的信息片段在它们各自有限的上下文中。事实上，我认为如果系统不是这样设计的话，这将是您计划如何设计系统的自然结果。

如果您的系统有登录名或组，并且文档保存在创建它们的登录/组中，那么这将达到上述目标。

我在把你的文档信息系统和公司的wiki进行比较。一个wiki可以被整个1000名以上的雇佣组织使用，它可能包含对一个人非常重要但对另一个人完全胡言乱语的页面，但是一切都很好，因为各个业务部门通常在wiki上都有自己的页面，而其他业务单位忽略了或者甚至不知道。

是的，您可能需要扩展您的应用程序，以涵盖更广泛和更广泛的受众，但这是任何实际应用程序的目标/噩梦。想一想任何数据库系统-它的目标是解决每个人的数据存储问题无处不在。他们做得多好是值得商榷的，但他们不可能失败，因为每个人都在使用它们。