RoRで市民権を得たActive Recordは、関連と継承をサポートすることによってドメインモデルとしても十分利用できることを示しました。Active RecordはもちろんDBに依存しますので永続化依存のドメインモデルです。 その一方でPOJOやPOCOなどインフラコードに…

アンチパターンで肥満児のオブジェクトがあるが、肥満児なドメインモデルってあまり聞かない。 ドメインモデルはデータアクセスや画面処理なインフラコード含まないので肥満児になりにくいのか？ 多くの依存関係をもつエンティティならば可能性があるかも。 …

トランザクションスクリプト的に記述した仕様書からドメインモデルを作ってもらうのは難しいよな。 設計書のような仕様書がかなり多い。*1 仕様書を書くトレーニングってあまりないんだよな。 DbC（Design by Contract）とか言うと難しく感じる人も多いし。 …

ドメインモデル貧血症のコードをC#の拡張メソッドを利用してリッチなドメインモデルのコードに近づけることができました。これはトリッキーな方法ではなく実用的な方法で、Active RecordやData Mapperと同じレベルのドメインモデル実装パターンと考えてよい…

前回まででドメインを利用するコードをかなりリッチにできました。ただ、サブルーチン的な構造化を機械的に行ってきたため結合度が低くく凝集度が高いコードにはなっていません。たとえば在庫判定処理。引数に予約を含めているのですがこれはかなり座りが悪…

引き続き、ドメインモデル貧血症のコードを再利用可能そしてドメインモデルをリッチ化することにチャレンジします。 前回、サブルーチン化することで処理の構造化を進め、プログラムが読みやすくなりました。しかし、まだ再利用するためには共通処理として利…

前回の続きです。まずは構造化的な発想で意味のある処理の塊を抜き出してみます。貸出処理の以下の部分については、「在庫がありません」の例外を返す部分で、３つのバリエーションがありますが、在庫判定処理として抽出できそうです。 var stock = context.…

ドメインモデル貧血症はダメなのか？でトップヘビーな設計なしで実装できるけれど、再利用性の割り切りは必要と考えていました。 しかし、これって本当なのか、再利用性のある貧血症のドメインモデルってできないのかなと疑問が湧き上がってきました。そこで…

ドメインモデル貧血症の実装は避けるべきなのか？ O/Rマッピング製品が充実してきている現状では特別など導入コストも少ないため、SQL文を記述するトランザクションスクリプトよりも、コードが短くなってメリットがあると考えられないか。トランザクションス…