阅读OSGi 应用程序设计后 - 我是否在滥用服务框架？以及将 OSGi 捆绑包组合成连贯的“应用程序”的最佳方法是什么，我现在陷入了如何应用“不要对 OSGi 编程”口号的棘手问题。
假设有界上下文是整个应用程序而不是单个包，我应该可以自由地在 API 包中声明一些聚合根实体，并以 DDD 样式声明用于处理所述实体的存储库。现在，问题的症结在于：显式存储库似乎与 OSGi 风格对立，因为存储库本身就是一个（域对象的）注册表，并且这种设计回避了 OSGi 服务注册表。但是要取消存储库将需要消费者对 OSGi 进行编程，以便执行实体的查找。
据说存储库只是一个门面——这是否意味着我应该创建一个委托给服务注册中心的存储库实现？这似乎不是一个连贯的方法，因为消费者将有两个进入域模型的入口点：存储库和服务注册本身。放弃存储库将不再是 DDD，因为我们回到了以意大利面条式的方式将域逻辑与框架代码混合在一起。
那么这里的要点是什么？领域驱动设计是否与“OSGi 方式”不兼容，还是我遗漏了一些关键概念？
不依赖于 OSGi 的理由是，作为中间件，代码中的 OSGi 可见性会降低它的凝聚力。域代码和 OSGi 代码不应混合（就像不应与 JMS、Java EE 或任何其他 API 混合一样）。内聚性较低的代码更复杂，因此容易出错。
但是，您总是需要一些将基础结构链接到您的域代码的桥接代码。由于这个桥接代码无论如何都会与某些 API 耦合，因此要充分利用它，从环境中抽象出桥接代码绝对没有用处。
DS（和 Blueprint、iPOJO 等）隐藏业务逻辑的注册表，它们只是提供域注册表的非常方便的方法。因此，使用 OSGi，您几乎不必编写任何代码来拥有一个非常强大的域对象存储库，而您的域对象本身并不知道 OSGi。
是的，如果您将代码从 OSGi 移动到其他地方，您必须重写桥接代码，并且来自 OSGi 世界，编写 OSGi 提供的通用功能非常大。但是，不使用 OSGi 构造，因为如果应用程序被移植，您必须提供功能是浪费金钱。
结论：域不应该与 OSGi 混合，桥代码应该充分利用 OSGi。
我认为您应该简单地将存储库注册为 OSGi 服务。需要存储库的包应该引用服务并且应该只知道存储库接口。当然，这意味着您必须在 Activator 中使用 ServiceTracker，或者在蓝图上下文中使用。我更喜欢蓝图上下文，因为这样你就不会对 OSGi 有真正的 java 级别依赖。
当然，这会以某种方式创建对 OSGi 的依赖，但这是无法避免的。要遵循的基本思想是，您应该将特定于 OSGi 的代码保留在业务代码之外，并将其放在单独的类或蓝图中。
请参阅我的一个教程，它展示了一个带有 UI、模型和持久性实现的简单应用程序。虽然应用程序太小而无法真正执行 DDD，但该方法应该是相当兼容的。您会注意到的一件事是整个应用程序不会导入单个 OSGi 接口。一个很好的副作用是您可以轻松地在 OSGi 之外重用代码，但是当然您必须以不同的方式解决 DI。