最近、私が働いている会社で、システムのランドスケープを再構築して書き直し、子供たちの未来を救うプロジェクトを開始しました。
恐ろしいコードのために新しいユースケースにまったく適応できない3〜4のレガシーシステムがありますが、電子メール、xmlrpc、webinterfaceなどのさまざまなインターフェースとフォーマットを介して、1日にかなりの量の注文を処理しています.
そこで、完全に再設計されたドメイン モデルに基づいて、新しいシステムをゼロから作成することを考えました。古いシステムを単純にオフにすることはできず、非常に小さなチームであるため、新しいシステムを徐々に開発し、その一部をライブで簡単に配置できるアーキテクチャとアプローチが必要であるという結論に達しました (read;高速）新しいインターフェース、パートナー、およびレガシーアプリケーションおよびインターフェースと統合します。
ドメイン モデル全体をゼロから完全に再設計し、注文サービスを作成し、OSGi コンテナーで Apache Camel を使用して、注文をレガシー システムと新しいシステムにルーティングする古いインターフェイスを模倣し、フォーマット処理とトランスポート自体を切り離すというアイデアでした。新体制から。段階的な開発のため、より「サービス中心」のアーキテクチャを選択したいと考えています。これにより、段階的な改善、再利用性、およびスケーラビリティが可能になります。紙の上ではすべてが良さそうに聞こえます。私は「SOA」についてかなりの量を読みましたが、誇大広告が消えて「良い部分」が残るのを待つまでは、話のほとんどはまだ非常に抽象的で不正確な「技術的」に関するものです。販売」レベルらしい。
非常に大きなグラフで、順序のような多くの関係を持つエンティティがある場合、「基本/共有データ サービス」アプローチは非常に問題があると思います。Orders およびその他のエンティティに対する CRUD 操作用の個別のサービスを作成して、より抽象的なエンティティのベースにする場合、ACID、リレーショナルの整合性を処理するのは本当に問題があるか不可能であるか、またはそれらのサービスの自律性を犠牲にして相互接続する必要があります。これにより、サービスがまったく役に立たなくなります (そして、おそらく非常に遅くなります)。それとも何か間違ったことを理解しましたか？
したがって、私の考えは、Nice JPA POJO を使用して (もちろんインターフェースを使用して) 「従来の」DAL を単純に作成し、それをビジネスおよびプロセス サービスが使用する単純なバージョン管理された OSGi バンドルとして展開し、より抽象的なマッピングを持つことでした。これらのサービスは、単純にそれを使用して、そのインターフェイスをバスに公開します。ラクダやバルク データ インポートまたはレポートでのコンテンツ エンリッチメントなど、個々のデータにアクセスする必要があるまれなケースに対応するために、ACID と整合性の問題を解決する醜い「すべてのエンティティを含むサービス」を作成できます。
ここまでは順調ですが、WebUI (前述のようにほとんどが CRUD であり、実際には抽象的なプロセスではない) はどのようにデータにアクセスすればよいのでしょうか? JPA POJO を直接使用すると非常に緊密に結合されますが、マッピングを作成して別のほぼ同一のモデルを導入し、前述の「モンスター DAL サービス」を使用するのもあまり良くありません。
どう思いますか？センス、エレガンス、実用性のバランスが取れているのはどこでしょうか?
質問が多くて文章が長くて申し訳ありませんが、私たちがここで直面している状況をもう少し詳しく描写することが重要だと感じました。
お時間をいただきありがとうございます:)