エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーション
アーキテクチャパターン
頑強なシステムを実現するためのレイヤ化アプローチ
を読んだ話（読み切ったとは言っていない）
y.katsumi

エンタープライズアプリケーションアーキテクチャパターン (Object Oriented SELECTION) |
マーチン・ファウラー, 長瀬嘉秀, 株式会社テクノロジックアート |本 | 通販 | Amazon

を読んだ話をします。
- 読み切っていません
- 私にとって馴染みのない事が多く、読み進められなかった。
- 辛うじて読み取れたところを解説します
- 自分の独自解釈が含まれています。
発表後修正しました。このスライドは独自解釈のみになります。

所属：スタジオアルカナ
名前：勝見　幸弘
年齢：34
サーバサイドメインのエンジニア
自己紹介

アーキテクチャ
いろんな意味を持ち人によってさまざま。
さまざま名中でも共通して言える要素は2つ。
・システムから個々のパーツへとどこまでもブレークダ
ウンできる
・簡単には変更できない決定事項。

いろんな意味を持ち人によってさまざま。
さまざま名中でも共通して言える要素は2つ。
・システムから個々のパーツへとどこまでもブレークダ
ウンできる
→大きいアーキテクチャの中に小さいアーキテクチャ
がいくつもあるとかそういう状態。
・簡単には変更できない決定事項。

有識者の意見を聞きます

こんなアプリケーション

・データは永続している必要がある。（プログラムの実
行終わったら消えるとかはこまる）
・データは大容量
・データは複数のユーザからアクセスされる
・エンタープライズアプリケーション同士で連携する
・時間とともに変化するビジネスプロセスが組み込ま
なくてはならない

エンタープライズアプリケーションの種類
なんかいろいろ言ってるけど結局は、
いろんな種類のビジネスがあっていくつもの検討事項
がある。
多種多様なシステムがあるのに「いつもこうする」と
言ってる人は警戒しろ。

システムを役割で分割することをレイヤ化という
→インフラで言えばIPレイヤとかTCPレイヤとか
・レイヤ間の依存は最小限にしましょう。
→IPの仕組みに変更が入ってもFTPは修正不要みたいな状態が良いよね。
・下位レイヤは上位レイヤに関心をもたないようにしましょう。
→使う側は使うものの性質を知っておく必要があるが、使われる側は使う側の性質は知ら
なくてよい。
レイヤ化

レイヤ化
レイヤ化にも弱点もある
・どこかのフィールド追加が入った場合、修正が上位レイヤに伝搬すると
きがある
・レイヤを追加した際パフォーマンス低下がある。（レイヤじゃなくてもそ
うじゃない？）
インフラを例にしましたががコードの実装も
レイヤ化が大切です。

主要な3つのレイヤ
1. プレゼンテーションレイヤ
• 画面表示（HTML）、HTTPリクエスト、コマンドライン呼び出し等
2. ドメインレイヤ
• システムそのもののロジック
3. データレイヤ
• データベース、トランザクションモニタ、その他のパッケージとの通
信
この本ではこの3つを扱うアーキテクチャについて解説している。
各レイヤ内でさらに細かいレイヤ（本ではレイヤとは言っていない）が存
在する。

アーキテクチャで似たよく見る図

サービスレイヤ
マーチン・ファウラー, 長瀬嘉秀, 株式会社テクノロジックアート |本 | 通販 | AmazonのP142

サービスレイヤ
依存する側
依存される側

これくらいなら実務で使えるんじゃないかな
と思えた図

テーブルモジュール

テーブルモジュールがドメインロジッ
クを持つ。
ただし、テーブルモジュールはテーブ
ルデータゲートウェイを直接触らない

データ取得の例）
1. プレゼンテーションがテーブル
データゲートウェイを使ってデータ
ベースからデータを受け取る
2. 取ってきたデータをテーブルモ
ジュールに渡して加工してもらう。
加工してもらったもの受け取って
戻す。

ドメイン駆動のエンティティとにてい
る？
ドメイン駆動のエンティティと違って
テーブルモジュールはデータを自分
で取ってこない？
有識者の意見ください

エンタープライズアプリケーションアーキテクチャパターン

Recommended

Recommended

More Related Content

More from Yukihiro Katsumi

More from Yukihiro Katsumi (11)

エンタープライズアプリケーションアーキテクチャパターン