ERP システムとやり取りするカスタム アプリの作成に主に取り組んでいる中規模企業で仕事を始めています。この種の仕事をするのは初めてなので、ERP の概念は私にとって初めてで、少しずつ学んでいます。
私はこれまでに 2 つのアプリしか作成しておらず、データベース モデルを学びながら、仕事を成し遂げるのに必要な分だけしか学んでいませんでしたが、その限られた量でも、全体像が形成されるのを見始めることができます。私の考えは、新しいアプリケーションがこのライブラリを参照できるように、すべてのマッピング/モデル オブジェクトが格納されたライブラリを作成することでした。その後、各アプリケーションは独自のリポジトリを作成し、必要なものと意味のあるパースペクティブのみへのアクセスを制限します。
私が抱えている問題/質問は、(N) Hibernate マッピング内の関係を処理する方法です。この基本ライブラリに完全な関係がマップされた注文オブジェクトがある場合、誰かがそれらの関係を永遠に移動するのを止めるものは何もありません (私が唯一のプログラマーであることを認めます...)。したがって、リポジトリを一種のスコープの限定として使用することは、この意味ではまったく機能しません。
代わりに、この注文オブジェクトの (N) Hibernate マッピングで関係を制限すると、リポジトリは、スコープに必要な関係のみにバインドされた注文オブジェクトを返します。欠点は、単一の「マッピング ストア」ではなく、プロジェクトごとにマッピングを作成する必要があることです。
他の人はこれにどのように対処しますか？
無関係ですが、(N)Hibernate の永続オブジェクトを変換して、いくつかの関係で構成されている可能性があり、特定のアプリケーションにより適した一種の単一の非永続オブジェクトに変換しています (通常は、UI の影響を大きく受けます)。これは一般的なことですか、それとも、返されたオブジェクトを取得して別のものに変換することで、(N) Hibernate の利点の一部を捨てているのでしょうか?
ps。DDDタグについて... これがDDDが詳細に対処するものかどうかはわかりませんが、本を注文しています. ただし、本が到着する前に見る良いリソースがわかりません。