0

最初に、ソフトウェアを開発するための私の標準的なアプローチは、おそらく多くの開発者にとって典型的なものであると言いたいです...動作が豊富であるが状態を持たないサービスと、状態のみを持ち、何も持たないオブジェクト (Bean) があります。動作 (これは通常、Anemic Domain Model と呼ばれると思います)。

新しいプロジェクトでドメイン駆動設計 (DDD) アプローチを試すことにしましたが、いくつかの問題があり、本当に困っています。

  1. 私の組織が使用している既存のサードパーティのデータベースがあります (そして、それはビジネスに密接に結びついており、これについて私にできることはありません: サードパーティが変更した場合にこれがどのように問題につながる可能性があるかについて言及するコメントは望みません)。データモデル...知っています!!)。データを表す休止状態のエンティティを作成しましたが、これを DDD の原則 (つまり、データ アクセスをカプセル化するリッチ ドメイン モデル) に準拠した内部モデル表現に変換する方法がわかりません。

  2. この種の問題にはパターンがあるはずですが、見つけるのが難しいと感じています。これは、私がおそらく間違った方法で何かをしている (つまり、通常のアプローチ方法ではない) と信じるように導きます。

私の現在の戦略は次のとおりです。

  • 休止状態のエンティティの中から主要なエンティティを特定し、これらを関連する値オブジェクトと一緒にパッケージ化しようとします (これは非常に困難でした。データから始めてドメインを作成しているためだと思います...アプローチ方法に関する提案はありますか?これも大歓迎です)
  • 特定したパッケージごとに、エンティティを管理するためのリポジトリを作成しました
  • 各リポジトリ (例: StudentHibernateRepository) で、必要な hibernate エンティティを取得し、それらをプロキシ クラスにラップします。
  • 各プロキシ クラスで、ラップされた hibernate エンティティをデータ ソースとして使用するために通過するビジネス ルールを追加します (ここでも、コードの動作をリッチにしようとしています)。

誰かが似たようなことをした経験がある場合は、経験/パターンを共有してください. また、私がとった戦略を振り返っていただけると助かります。

乾杯、

Jラブ

4

1 に答える 1