DDD视角下的框架是什么？

Question

框架以通用方式解决问题，因此如果我们想在我们的应用程序中解决相关问题，我们可以重用代码和语言。我们通常通过集成来满足它们，但是如果我们有一个实现完整子域的框架呢？例如识别和授权？我们应该使用它吗？从DDD的角度来看，这是一个有限的背景吗？

Answer 1

决定，如果购买或建造

我们是某种security domain（我们的core domain）。我们将构建的安全软件将成为我们的company advantage 在这里购买/使用一些公共授权组件是没有意义的。我们需要continuously make such component better 如果我们不这样做，我们公司将stop increasing its business value，我们不能允许这样做。

另一方面，如果我们在selling domain，我们may want to want to use external component 这是related with time，我们需要花费在构建/维护它上 如果这是一段时间we will lose time我们可以花费incresing our business value来销售组件 我们也可能有no security experts，因为它不是我们的域名。我们可能会阅读一些书籍/文章，但我们可能不会提供与核心域名为安全性的公司一样好的软件:) 这就是为什么我们应该考虑购买这样的组件。

当它只是Subdomain并且它变成Bounded Context

时

 "What is it from DDD perspective, is it a bounded context?"

有界语境作为一个术语是非常抽象的 从我的角度来看，当我们有

时，我们可以谈论有界的上下文（好的，与子域一对一）

• 一个应用程序
• 模型，由UL
包围
• 公开外部API的应用程序，因此其他应用程序可以与之通信
• 可能包含所有模型状态的存储空间。
• 运行应用程序所需的所有基础架构

它的定义框架只是一个框架，你不能只下载框架并运行它。它不会提供任何价值。 因此框架只是帮助我们围绕某个子域构建有界上下文，但它本身并不提供BC。

使用外部组件/框架

如果它的组件已准备好部署并公开某些API，那么我们将使用集成模式。

"what if we have a framework which implements a complete subdomain?"

如果它是一个框架，那么根据需要。

1. 我们可以build a bounded context around it，通过添加一些代码并公开一些外部接口。
2. 我们可能add it, to our bounded context可能正在描述其他一些子域名。只要它不破坏我们的模型就没关系 我们有限的上下文将覆盖多个子域。子域名应位于以UL命名的单独包中 您可能希望尽可能减少这两个模块之间的连接 您甚至可以在域级别上构建ACL。这只是为了帮助您的模型成长，而不必考虑其他所有子域的复杂性。把这段代码想象成你可能希望有一天切断它并与它集成的公共接口。

Answer 2

实际上，根据您的框架，它也可能是域名服务。

例如，一个实现service.IsAuthenticated（someDomainObject）的框架似乎是一个非常合理的服务。

Domain Driven Design: Domain Service, Application Service