私はプログラマーであり、OOについて十分な教育を受けていると思います。POCO（C＃）と、データをカプセル化するためのget/setメソッドしかないモデルを信じています。3層ドメインモデル。
シンプルなドメインモデルとサービスレイヤーのすべてのビジネスロジック、およびデータアクセス用のDALを持つことの価値をサポートするドキュメントを探しています。
マーティンファウラー：
http://martinfowler.com/eaaCatalog/domainModel.html
http://martinfowler.com/bliki/AnemicDomainModel.html
（貧血の）ドメインモデルには価値がなく、価値を持たせるには、buslogicまたは/およびdataCRUD操作を処理する必要があると言っています。マーティン・ファウラーに反論する良い本が必要です。（これはマーティン・ファウラーを解任する場合ではありません。私はその仕事を尊重します。私たちが何をしているのか、そしてその理由をよりよく理解したいと思っていますか？）
ファウラー自身からの反論を見つけることができます。
PoEAA、p。110、取引スクリプト:
どんなに物好きになっても、トランザクション スクリプトを除外しないでください。世の中には単純な問題がたくさんありますが、単純な解決策を使えば、はるかに迅速に作業を開始できます。
トランザクション スクリプトは、あなたが説明した種類のサービスではありません (ドメイン オブジェクトを使用しない可能性があり、貧血のオブジェクトも使用しない可能性があります) が、非常に近いものです。
また、POCO の概念は、オブジェクトの愚かさや貧血について何も想定していないことに注意してください。動作を含む豊富なドメイン POCO を使用できます。POCO/POJO は、アノテーションや属性で装飾されたオブジェクトや、多くの場合永続化の目的でフレームワークから特別なクラスを継承するオブジェクトとは対照的に、単純なネイティブ オブジェクトを記述します。
Fowler、貧血ドメインモデルを引用：
本質的に貧血ドメイン モデルの問題は、ドメイン モデルのすべてのコストが発生し、メリットがまったく得られないことです。
コストには、オブジェクトをデータベースにマッピングすることと、(乏しい) ドメイン モデルの設計に費やす労力が含まれます。DDD のメリットが不要であり、貧血モデルに関連するコストが許容できると判断した場合は、反論が必要です。
ただし、貧血モデル + サービス + DAL (+UI?) が、いくつかのトランザクション スクリプトを使用したアクティブ レコードアプリケーション (Ruby on Rails? Grails?)よりも安価であることを確認してください。
ドメイン駆動設計は通常、単純な問題を「複雑化」するのではなく、複雑な問題を単純化したいときに適用されます。再びファウラーを引用：
ドメイン モデルは常に最適なツールとは限りません。
要件を分析し、適切なアーキテクチャを選択して、アプリケーションを提供します。
DCI アーキテクチャを見てみましょう。DCI アーキテクチャは、データと動作を分離し、変化率が異なる部分を分割することでソフトウェアの進化を制御しようとします。また、ロールまたは特性の概念を使用して、データと動作を元に戻すという目的の機能を実現します。
DCI を強調するアーキテクチャのより広い主題に取り組む本があります: James Coplien によるアジャイル ソフトウェア開発のためのリーン アーキテクチャ。