販売注文エンティティの責務を分解して整理する 販売注文はイベント（トランザクション）系のエンティティです。対応するテーブルには状態値や区分や種類が含まれています。これらを責務を識別して分離することで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で開発する場合、データベースをもとに概念モデルや組み立てていく必要があります。しかし、なまじ詳細なテーブル情…