ＤＯＡ（ものこと分析）とＤＤＤ（ドメインモデル）について一言 ＤＯＡはシンプルな分析方法で失敗がすくない。でも表現力の幅が小さい。 ＤＤＤは抽象化など俗人的な面もあり、だれでも使える方法ではないが、表現力が豊か。どっちがいいかは状況によるが…

おまけとして、今年考えさせれたことを書いておきます。今年いくつかの海外で作成されたパッケージ製品のアーキテクチャを調査していたのですが、普通にDomain Modelで作成され、RESTインタフェースでバージョニングなども行われていて綺麗な作り方になって…

.NETのDDDのサンプルで、Code-FirstとMVVMで作っているようです。ざっと見た感じですが、素晴らしい！！ 内容を見てみると、DDDのEntityやValueObject、（Domain）Service、その他Specificationなど多くのパターンについて実装と解説がついています。ドキュ…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

純粋ORMであるNHibernateと流れるようなインタフェースでSQL文作成するSubsonicについて Subsonicの学習コストが低いようなコメントが多いですね。S2JDBCも同じようなメリットをうたっていたと思う。 この点は（人数が多い）大規模プロジェクトには有利なん…

こんなサンプルがあるのは知らなかった かなり前からあるのかな、気付かなかった

DDDについて、いろいろなことが書いてあるけど、目新しいことはないかな。Project Managementの視点でDDDを語っているのは興味があったけど、それほど深い洞察があるわけでもない。 今だとメタプログラミングやDSLの視点でDDDを語ってほしいな。あと、サンプ…

ERモデルをベースにドメインモデル的に作成する方法。設計モデルがなくてもコーディング時に比較的簡単に導入できるビジネスルールのロジック。 エンティティ内で計算できる導出項目の定義 金額=単価x数量 自エンティティの検証ロジックの定義 予約.Validate…

ドメインモデルは複雑なアプリに有効だが、データ入出力中心の業務アプリにはマッチしないような意見をよく聞く。そうなんだろうか？ RoRはドメインモデル実装だと考えている僕にはそう思えない。RoRでデータ入出力中心のアプリを作るってすごく簡単だよね。

DDDのサンプルプロジェクトって見かけないなと思っていたら案外あるのですね。いろいろ参考にさせてもらおう。.NETでの実装もいろいろあって、.NETの世界でもDDDも認知されてきたということか。テクノロジー的にはNHibernateが多いようですね。このあたりはL…

いま、DDDのメーリングリストで各地域でのDDD-erを探しているようですね。日本のDDDのユーザ会とかないのかな？DDD会議とかあってもよいのにな。あったら行きたいな。

前回ドメインモデルにLINQ to SQLのメタ情報を付与して永続化の仕組みを構築しようと考えましたが、LINQ to SQLが要求するいくつかのインタフェースを実装するためにドメインモデルをかなり変更する必要があり断念しました。 今回は違う方法でチャレンジしま…

データベースを定義せずにドメインモデルを利用して開発を進めてきました。画面も含めて特に問題なく開発することはできました。作成されたドメインモデルはこんな感じになっています。 [Serializable] public partial class Message : IValidator { public …