<< システムの歪め方 【アンチパターン】 | main | アプリケーションの中核 : 関心事オブジェクト 【パターン】 >>

エンタープライズアプリケーションのモデリングパターン

ドメインモデリングの基本パターンをまとめはじめてみた。
まずは、その概要のスナップショット。

関心事オブジェクト


事業の関心事を表す
エンタープライズアプリケーションは、「事業の関心事」を扱うための道具。

だから、モデリングパターンの基本は、事業の関心事を表現した「関心事オブジェクト」。

関心事オブジェクトは、

◎ 識別キー (名前、番号など、関心事を特定するための情報)
◎ 固定属性 (商品の説明、連絡先など、通常は、あまり変化しない属性)
◎ 変動属性 (変化することが正常で、変化しないことが異常な属性)
◎ 集約キー (グルーピングや集計のキー)

で構成する。

そのアプリケーションの主要な関心事を、「関心事オブジェクト」としてモデリングする。

状態の変化


状態の変化
エンタープライズアプリケーションは、関心事オブジェクトの「状態の変化」を扱うための仕組み。

◎ 関心事オブジェクトの状態が、変化するのは、どういう時か?
◎ 関心事オブジェクトの状態が、変化した時には、何が起きるべきか?
◎ 何を記録すべきか? 何は記録する必要がないか?

状態の変化を扱うモデリングと設計・実装パターンが、エンタープライズアプリケーションの基本機能になる。

予実管理


予実の管理
「状態の変化」の中でも、「予定」とか「約束」という、こうあるべき、という「未来の状態」と、実際に起こった「過去の事実」と「現在の状態」を管理することが、エンタープライズアプリケーションの中核機能になる。

予定−実績−差異−行動、つまり、Paln-Do-Check-Action PDCA が、ビジネスの基本活動。
この基本活動を支援する道具が、エンタープライズアプリケーション。

予実管理の関心事は、一件の注文の予定と実績の管理、という粒度から、事業全体の予算と実績の管理までと、幅が広い。

どの粒度では、PDCA のモデリングと設計・実装のパターンはいっしょ。

「予定」とか「約束」は、単独であれば、管理がしやすいが、問題は、それが複合した時。
「複合した予定」を扱い方が、エンタープライズアプリケーションの重要な課題。

「スケジュール」は、複数の予定の、依存関係、特に先行/後続関係を扱うためのパターン。
「契約」は、利害の異なる登場人物が、お互いに約束を交わすことを扱うためのパターン。

また、「予実の管理」は、ビジネスルール、ビジネスポリシーの宝庫。

「予定」は、「未定」。いろいろな想定の上に存在する「仮の状態」。
これを、すんなり「実際の状態」にできれば、みんなハッピーなんだけど、そうはうまくいかない。

そのうまくいかないことを、なんとかうまくできる割合を増やそうとしたり、あるいは、うまくいかなかった場合の取り決めが、ビジネスルールとか、ビジネスポリシーということ。

アーキテクチャそして実装


エンタープライズアプリケーションを実現するには、概念モデルだけでは、意味がない。

動くソフトウェアになって初めて価値がある。
そのためには、良いアーキテクチャ、フレームワークの活用、実際のコードが必要。

個々のモデリングパターンを書くときに、具体的に触れようと思うけど、ベースになるのは、

◎ メッセージング
◎ REST : Representational State Transfer

の二つのアーキテクチャスタイルだと思っている。

あとは、記録(永続化)と通知(メッセージング)のフレームワークをうまく使う。
人に使ってもらうんだから、MVC フレームワークも必要。

ドメイン層自体には、そのまま使えるフレームワークはないと思っている。
ドメイン層以外は、適切なフレームワークを使うことを想定している。

フレームワークの本質は IoC : Inversion of Control だと思っている。
ようするに、 if 文、 for 文のような制御文は、フレームワークにまかせて、アプリケーション開発者を、わずらわしい制御( if 文 や for 文 ) から解放してくれる便利な道具というのが私の理解。

アプリケーションソフトウェアは、どんどん宣言的なコーディングスタイルになっていく、というわけだ。

個々のパターンを、説明する時は、ここらへんの実装の話を、できるだけ具体的な業務を題材にして、モデルやコード(の断片)を使いながら書ければいいな、と思っている。

自分の頭を整理するために。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
<< September 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM