これは貧血ドメインモデルですか？

Question

私は最初のCRUDアプリケーションを構築しようとしていますが、ゲッターとセッターを分離したオブジェクトを使用する必要があるかどうかはわかりません。

私たちが持っていることを考えると Zend Frameworkクイックスタートチュートリアル を含むモデル構造で：

• ゲートウェイ
• データマッパー
• ドメインオブジェクト（モデルクラス）

ドメインオブジェクト（Zend Quick Startチュートリアルで表示されているように）がゲッターとセッターのみで構成されている場合、それはアンチパターンですか？ある意味では、ドメインオブジェクトをトランザクションスクリプトで不必要に分割していますか？

お知らせ下さい。

Answer 1

ドメインオブジェクトは、ソフトウェアのビジネスロジックから分離されています。これは重要なアイデアです 手続きプログラミング.

ただし、このパターンは、一部の開発者によるアンチパターンの候補であると考えられています。つまり、効果のない実践である可能性があります。

実際、あなたは欠点を考慮することができます

• あなたのモデルはそれほど表現力がありません、ゲッターとセッターはモデルを説明するのに本当に良くありません
• コードの再利用は難しく、トランザクションスクリプトの中で波打つコードを取得します
• 実際のデータ構造を隠すラッパーを使用する必要があります（したがって、実際にはoopではないかもしれません）
• エンティティへのグローバルなアクセスが常にあります

考慮すべき最も興味深いポイントは、ドメインモデルのオブジェクトがいつでも正確さを保証できないということだと思います。それらの突然変異は分離された層で起こるからです。

私もZend Frameworkを使用してCRUDアプリケーションに取り組みました。ロジックとデータの明確な分離は本当に素晴らしいですが、進行すると、レイヤーとマッパーの量が大きくなり、大きくなることがわかります。できる限りコードを再利用し、波打ちを避けてください。

Answer 2

貧血ドメインモデルは、真のドメインモデル（ドメイン駆動デザインの別名ドメインモデル）を構築しようとしている場合にのみ、抗パテランです。

単純なCRUDアプリケーションの場合、貧血ドメインモデルはおそらくベストプラクティスです。特に、あなたの仕事を非常に簡単にするフレームワークがある場合。

Martin Fowlerの記事についての記事をご覧ください 貧血ドメインモデル そしてまた グレッグ・ヤングの記事.