阅读后OSGi application design - am I abusing the service framework?和 What is the best way of grouping OSGi bundles to make a coherent 'application' ，我现在陷入了一个紧迫的问题，即如何应用“不要对 OSGi 进行编程”的口头禅。
假设有界上下文是整个应用程序而不是各个包，我应该可以自由地在 API 包中声明一些聚合根实体，并以 DDD 风格声明一个用于处理所述实体的存储库。现在，问题的关键是:显式存储库似乎与 OSGi 风格相反，因为存储库本身就是(域对象的)注册表，而这种设计回避了 OSGi 服务注册表。但取消存储库将需要消费者对 OSGi 进行编程，以便执行实体的查找。
据说存储库只是一个外观 - 这是否意味着我应该创建一个委托(delegate)给服务注册表的存储库实现？这似乎不是一个连贯的方法，因为消费者将有两个进入域模型的入口点:存储库和服务注册表本身。放弃存储库将不再是 DDD，因为我们又回到以意大利面条般的方式将领域逻辑与框架代码混合在一起。
那么这里的要点是什么？领域驱动设计是否与“OSGi 方式”不兼容，或者我是否遗漏了一些关键概念？
最佳答案
不依赖 OSGi 的理由是，作为代码中的中间件 OSGi 可见性会降低其内聚性。域代码和 OSGi 代码不应混合(就像它不应与 JMS、Java EE 或任何其他 API 混合一样)。内聚性较低的代码更加复杂，因此容易出错。
但是，您始终需要一些桥接代码将基础结构链接到您的域代码。由于该桥接代码无论如何都会与某些 API 耦合，因此要充分利用它，将自己从桥接代码环境中抽象出来绝对没有任何用处。
DS(以及 Blueprint、iPOJO 等)隐藏业务逻辑的注册表，它们只是提供域注册表的非常方便的方法。因此，使用 OSGi，您几乎不需要编写任何代码来拥有非常强大的域对象存储库，而域对象本身不知道 OSGi。
是的，如果您将代码从 OSGi 移动到其他地方，您必须重写桥接代码，并且来自 OSGi 世界的 OSGi 提供的通用功能的编写量惊人地大。但是，不使用 OSGi 构造是因为在移植应用程序时您必须提供功能，这会浪费金钱。
结论:域不应该与 OSGi 混合，桥接代码应该充分利用 OSGi。
关于domain-driven-design - OSGi 应用程序设计和 DDD，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12771844/