これはいい。Symbols in C# 3.0 http://themechanicalbride.blogspot.com/2007/03/symbols-on-steroids-in-c.html以下のようにobjectクラスを拡張すると public static string GetPropSym<TObj, TProp>( this TObj @this, Expression<Func<TObj, TProp>> expression) { return ((MemberExpre</func<tobj,></tobj,>…

"... 制御することに着目すればするほど、相対的に小さな価値を提供するプロジェクトで一生懸命働いているような気がする。 私としては、ソフトウエア開発プロジェクトを制御する方法よりも大きな問題は、一体なぜプロジェクトの多くが、とるに足らない価値…

案外Genericsって使われていない？でも書いたけどDIでGenericsをサポートする要望は多いはずなのに。残念。回避方法はあるのかな。元ねたは以下です。MEFはタイプベースじゃないんですねWhy doesn’t MEF support open-generics for exports? Because MEF is …

販売注文エンティティの責務を分解して整理する 販売注文はイベント（トランザクション）系のエンティティです。対応するテーブルには状態値や区分や種類が含まれています。これらを責務を識別して分離することで1クラス1責務に近づけて安定化します。まずSt…

次はイベント系のエンティティを分析・設計してみる 前回はリソース（マスタ）系の従業員エンティティを対象にしました。今回はイベント（トランザクション）系のエンティティを分析・設計していき最終的にはドメインモデルで実装するようにします。 Adventu…

ドメインモデルにサービスを導入する サービスというといくつかあるのですが、ここではSOAやFacadeなどのテクニカル的なものではなく、ビジネス・オブジェクト*1が提供する機能のサービスを指します。このため、ここでのサービスは画面や通信、永続化メカニ…

VALUE OBJECTを利用してエンティティ内のデータをグループ化する VALUE OBJECTの使うことでより粒度が小さく1クラス1責務に近づけることができます。連絡先エンティティも情報グループごとにVALUE OBJECTで切り出すことができます。Castle ActiveRecordの場…

今までの作業の中心はエンティティだったのでDOA（データ中心アプローチ）と同じような作業と感じを方もいるかもしれません。ビジネスデータの中心は確かにエンティティなのですが、VALUE OBJECTを上手に利用することでビジネスロジックの記述をより高いレベ…

今回から分析した従業員エンティティをドメインモデルで実装していきます。 Castle ActiveRecordを使ってみる 今回の実装で利用するＯＲマッパーは何にしようか悩んだのですが、マッピングの自由度やプログラムの対応のわかり易さなどを考えてCastle ActiveR…

分析モデルを安定化させ設計モデルに整理する ビジネスルールを記述するためにエンティティの機能定義を行ったので、次は実際に実行可能な設計モデルに整理します。ここではビジネスオブジェクトをどのように実装するかを考えていきます。 実装の観点として…

ビジネスルールの識別はロバストネス分析の利用もお勧め 前回識別したビジネスルールですが、分析にはロバストネス分析を利用する方法もやり易い方法です。ユーザ機能からサービスを識別してビジネスルールを整理します。 ビジネスルールで利用された用語を…

今回はユーザ機能を分析してさまざまなビジネスルールを識別していきたいと思います。 ビジネスルールとは ビジネスルールを表現にするという風に書いていますが、そもそもビジネスルールについて少し整理しておきます。オブジェクト指向方法序説（ジェーム…

前回は、従業員（Employee）エンティティに関連するテーブルを分析して、静的な構造を識別しました。さらに役立つモデルにするためにビジネスルールを記述可能になるように分析モデルをリッチ化します。 エンティティのデータを確認する まずは、今回ターゲ…

前回の補足 識別子からエンティティ候補を分析している表に区分という項目があり「イベント」「リソース」などと記述してます。これがエンティティの種類をあらわしているのはある程度想像してもらえると思っています。ただ、「汎用」や「ルール」など少し一…

都合の良いシナリオでサンプルを作成するのではなく、既存のDBを使って実際に概念モデリングを行い、ドメイン駆動設計からドメインモデルにつなげて行きたいと思います。 ターゲットのデータベース AdventureWorksのテーブル定義はここにあります。並べると…

既存システムの刷新をする場合などは、既存のデータベース設計があってそれをベースを開発を進める場合があります。このようなケースでOOADで開発する場合、データベースをもとに概念モデルや組み立てていく必要があります。しかし、なまじ詳細なテーブル情…

Naked Objects for .NET - 生産性の高い.NETフレームワーク Naked Objectsについては以前から興味がありました。ドメインモデルを作るとUIが自動的にできるこの魅力は大きい。ある意味ドメインモデルをメリットを最大化したような仕組みですからね。 ただど…

ドメイン駆動設計の記事がInfoQに見つけた なかなか良いことが書いてある。うむうむ軽く読み流した。 サンプルがあったのでダウンロードしてみるとDomainにロジックがほとんどない？ しかもドメインモデルにCRUDメソッドがある。これは新しいアプローチか？ …

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

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

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

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

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

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

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

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

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

MSDNマガジンにDDDの概要が載っています。 コンパクトな記事ですが、実装開発者向けにポイント良く紹介されています。.NET使い以外の方も一読をお勧めします。ドメイン サービスをIoCで解決させるなど実践的なTIPSがチラリと入っています。#集計ルートって訳…

まずは、ベースになるWindowsアプリケーションの画面処理です。よくあるコードで、4桁までの数値を入力検証します。このコードを改善していきます。 textBox1.MaxLength = 4; textBox1.ImeMode = ImeMode.Off; textBox1.Validating +=new CancelEventHandler…