<< event とメッセージング 【きっと、良いパターン】 | main | 業務のモデリング 【プロトコルモデリング】 >>

イベントソーシングスタイルを実装する

採用業務の状態管理の仕組みをモデリングしている。

状態管理を、イベントソーシングスタイルで、やるための、大まかなクラス構成を絵にしてみた。
それぞれのクラスの役割をできるだけ、単純明快にすることを、重視した。

関心ごとの分離( SoC : Separation of Concerns )原則、 単一責任原則 ( SRP : Single Responsibility Principa ) をこころがけたつもり。

イベントソーシングの実現モデル

メッセージング / Web アプリケーション


上半分は、メッセージングのフレームワーク Mule ESB での実装をモデル化したもの。
下半分は、(今までやってきた) Web アプリケーションの MVC モデル、サービス層/ドメイン層/インフラ層のレイヤ構造を整理したもの。

Mule ESB のサービス部品と、Web アプリで使う Service クラスとは、完全に一致していない。
どちらも、薄いファサードで、実際の責務は、下のドメイン層のクラスに委譲するのは、同じパターン。

たぶん、コアのサービスクラスを作って、それを、 Mule ESB 用にラッピングしたクラスと、Web アプリケーションのサービス層用にラッピングしたクラスを、それぞれ用意することになると思う。

ドメイン層のイベント処理モデル


Event と Document


Event クラスは、シグナルに近い。 単純に「変化があった」ことだけを表現する。
Document クラスは、その event に付随する「その時の状態」を表現したもの。

この二つは、発生時点の状態を、feeze して記録する。つまり、不変(immutable)オブジェクト。

State


State オブジェクトは、業務上の関心のあるオブジェクト。
「現在の状態」とか「履歴」とか「次にやるべきこと」、「予定日時」とか、業務上、参照したい情報を置いておく場所。
図には描いていないけど、State オブジェクト ( リファレンスオブジェクト、または Entity )は、参照用の識別キー(ID とか管理番号)が必須の属性。

こちらは、業務で変化が起きるたびに、状態を変更していく 可変 ( mutable ) オブジェクト。

Procedure


Procedure クラスは、ドメイン層内部のレイヤ構造で、上位レイヤ(Policy層)に位置するオブジェクト。
このクラスに、
・ある event が発生したら、何をすべきか
・State オブジェクトの状態と、その変更の妥当性 (有効な状態遷移)
などの「業務手順の知識」を記述する。

実装技術


この絵で、白い背景の要素は、フレームワーク側で用意している仕組みや部品で実現しようと思っている。

Mule ESB だと、 inbound/ountbound 、メッセージ routing 、例外処理、などは、いろいろ部品がそろっているので、ビジネスロジックコンポーネント( Service クラス )と、委譲先のドメインクラスを設計・実装して、組み立てるだけ。
(というか、ドメイン駆動設計でやっているので、ドメイン層は、サービス層を実装する時には、できあがっている)

Web アプリケーションも、 コントローラーは、 Spring 3 MVC と、 Spring Web Flow が用意されているので、それを活用する。

いままでのシステムでは、 Validation は、if 文とか使って、validation 用のメソッドを、ごりごり書いていた。
今回の案件では、 JSR-303 Bean Validation を全面的に採用することにチャレンジ中。
アノテーションで、 @NotEmpty とか @Length とか、宣言するだけで、検証は、フレームワークがやってくれる。
if 文が、激減する。

O-R Mapping フレームワークとか、Java の Collection フレームワークを活用するようになって、もともと、for 文は、ほとんど、コードに登場しなくなった。

今回、アノテーション方式の Validation フレームワークを導入したので、if 文も、ほとんど見かけなくなる予定。

たぶん、サービス層やドメイン層で、if 文や for 文を発見したら、「いやな臭い」として、ドメインモデルの設計改善ネタにしてまちがいなさそう。

if 文や、for 文が激減していくのは、まさに、IoC ( Inversion of Control ) ですね。
「プログラムの制御文(control)」は、どんどんフレームワーク側に移動して、アプリケーション開発は、どんどん、宣言スタイルに進化(?)していく。

モデリングして、それを、アノテーションや XML で宣言、以上終了、という感じ。
テスト記述も、どんどん、アノテーションと、XML になってきちゃっている。

開発という仕事は、制御構造(if分岐、forループ)にどっぷりつかった「プログラミング」から、ドメインを表現する「ライティング」に大きくシフトしてきた感じ。


コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< May 2018 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
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