OSGiアプリケーションの設計を読んだ後-私はサービスフレームワークを悪用していますか？そして、一貫性のある「アプリケーション」を作成するためにOSGiバンドルをグループ化する最良の方法は何ですか、私は今、「OSGiをプログラムしない」というマントラをどのように適用するかという疑問に悩まされています。
制限されたコンテキストが個々のバンドルではなくアプリケーション全体であると仮定すると、APIバンドル、およびDDDスタイルで、そのエンティティを操作するためのリポジトリで、任意の集約ルートエンティティを自由に宣言できます。さて、問題の核心は、リポジトリ自体が（ドメインオブジェクトの）レジストリであり、この設計がOSGiサービスレジストリを回避するため、明示的なリポジトリはOSGiスタイルとは正反対のように見えることです。ただし、リポジトリを廃止するには、エンティティのルックアップを実行するために、コンシューマーがOSGiをプログラムする必要があります。
リポジトリは単なるファサードであると言われていますが、これは、サービスレジストリに委任するリポジトリ実装を作成する必要があることを意味しますか？コンシューマーはドメインモデルへの2つのエントリポイント（リポジトリとサービスレジストリ自体）を持っているため、これは一貫したアプローチではないようです。ドメインロジックとフレームワークコードをスパゲッティのように混合することに戻ったため、リポジトリを放棄することはDDDではなくなりました。
では、ここでのポイントは何ですか？ドメイン駆動設計は「OSGiの方法」と互換性がありませんか、それともいくつかの重要な概念が欠けていますか？