MVVMパターンの構築手法その３のセッションで、ビジネスエンティティがドメインモデル形態の実装で、ビジネスワークフローやビジネスコンポーネントがトランザクションスクリプト形態の実装という説明に違和感を覚えた方もいらっしゃるようです。
特に JAVA を長年やっていた方はそう感じたようです。
ADO.NET の DataSet や LinqToSQL や Entity Framework はドメインモデルを構築しやすい構造になっています。
WCF RIA Services で提供されるのは、ドメイン サービスでクライアントにドメインモデルを構築しやすい構造になっています。
つまりビジネスエンティティにデータベースサーバーのデータベースの必要なサブセットを構築しやすいようになっています。
なおかつエンティティはパーシャルで拡張できビジネスルールを作成できます。
リッチクライアントでは起動時やログイン時に必要なデータをサーバーより取得してきて、UIによる変更情報をビジネスエンティティに蓄え、ユーザーの保存ボタンなどのアクションによってサーバーに保存します。
ビジネスエンティティはデータベースのサブセットとしてドメインモデル形態の実装を行うのが自然です。
トランザクションスクリプトはMartin Fowlerの造語ですが、 プロシージャスタイルのことで、プロシージャは最初に必要なデータを取得して更新情報を作成してSQLなどの更新手段を作成して実行します、この間にビジネスルールは一般に入りません、データベースサーバーがビジネスルールを持ち結果をプロシージャに返します。
ビジネスワークフローやビジネスコンポーネントはユースケースの実現を行うことに主眼を置きます。
ビジネスワークフローは１ユースケースの成功の脚本や代わりの脚本や失敗の脚本をトランザクション的に行い事後条件を満足することを目的とします。
ビジネスワークフローはビジネスコンポーネントに依頼して必要な情報をビジネスエンティティから取得します、更新情報を作成して更新手段となるビジネスコンポーネントを利用してをビジネスエンティティを更新します。ビジネスエンティティはビジネスルールを持ち更新結果を返します。
つまり、ビジネスワークフローとビジネスコンポーネントはデータベースではなくビジネスエンティティに対してトランザクションスクリプトのプロシージャスタイルを行っています。
ビジネスエンティティがドメインモデル形態の実装で、ビジネスワークフローやビジネスコンポーネントがトランザクションスクリプト形態の実装という意味を理解していただけることを期待します。
補足情報としてアプリケーションアーキテクチャ２．０におけるビジネス層の形態とユースケースの例を添付します。
|
ユースケース名 |
受注 |
|
アクター（かかわる人やサービス） |
販売担当者、仕入販売システム |
|
トリガー（起点） |
顧客よりの受注 |
|
ガード（事前条件） |
なし |
|
目標（事後条件） |
在庫不足があれば仕入指示して在庫不足を解消し出荷指示をする |
|
脚本 |
1.在庫照会をする
2.在庫があれば出荷指示する |
|
代わりの脚本 |
2a.在庫が不足があれば仕入指示する
3.出荷指示する |
|
失敗の脚本 |
|