reading エンタープライズアプリケーションアーキテクチャパターン 1.概要
•Transferir como PPTX, PDF•
2 gostaram•5,706 visualizações
社内勉強会で使ったスライドです。何回かに分けて解説していく予定で本スライドは「はじめに」の部分になります。
Recomendados
Mais conteúdo relacionado
Semelhante a reading エンタープライズアプリケーションアーキテクチャパターン 1.概要
Semelhante a reading エンタープライズアプリケーションアーキテクチャパターン 1.概要 (20)
reading エンタープライズアプリケーションアーキテクチャパターン 1.概要
- 2. はじめに • この発表の対象者 • 仕事で業務アプリ（B2B/B2C問わず）を書くあらゆる人 • 話すこと • 本書の概要と構成 • 本書の良い所・難しいところなど • 対象ドメイン • 話さないこと • 各パターンの詳細（次回以降で何回かに分けて解説予 定）
- 3. About • エンタープライズアプリケーションアーキテクチャパターン • 原題: Patterns of Enterprise Application Architecture • Martin Fowler • 日本語版は翔泳社から出ているので、たまにKindleで値引きして いる • Kindle: 6,264円 / 物理本: 〜6,264円
- 6. 本書の訳はひどいのか？ • 確かにひどい所もあるが、原著になるべく忠実に訳したタ イプの翻訳書だと思えばないよりはましレベル • 固有名詞をカタカナ語のまま訳しているケースが多かったり、たま に変な直訳（訳さなくても良い語の訳）がある • ひどい誤訳もそこそこある（おかしいと思ったら原著見た方が良 い） • とはいえ原著で全部読むのも大変なので、意味はあるかな • そもそも読みにくいのは原著のせいもある • 文章はわかりやすいが抽象度の高い言葉・用語が多く、各用語の 意味を確実に捉えて読まないと意味が掴めない（恐らく訳者もそう いう点で意訳を諦めたんだと思う） • 初心者向けとはとても言えない内容で、少なくともそれなりの数・大 きさのシステムの設計経験者でないと理解が難しい難易度 • サンプルソースが全体的に古め（Java/C#）
- 7. 本書に必要な前提知識 • GoFのオブジェクト指向設計・デザインパターンレベルの知 識 • 当然理解しているものとして用語が出てくるので、理解があいまい ならまずそちらを • Web及びRails等のフレームワークに閉じないアプリケー ション設計知識 • RailsでしかWebアプリ書いたことなくて、Railsの設計もまともに説明 できない人にはかなりむずかしい（少なくとも一人で読むのはつら い） • フレームワークの設計に関する知識や、オレオレフレームワーク・ ラッパークラス等を書いた経験などがあると理解が深まりやすい • 様々なコンピュータサイエンス用語の正確な理解 • 元々曖昧な用語については初出時にスコープの解説があるが、一 般に使われる用語については解説なしで使われるので語彙が必 要 • 通常この手の技術書は7〜8割くらいの用語が分かれば残りは意 訳で読み進められるが、この本は9割くらいの用語を理解できない とよく分からなくなる印象
- 8. 本書はどういう人にためになるのか？ • 機能レベルではなく、アプリケーション全体レベル の設計を行うアーキテクト • GoFのデザインパターンよりも1段階広い範囲 • エンタープライズアプリケーションにおけるよくある設計 に対して名前を付け、設計の議論の精度を高める • 色々なプロジェクトを渡り歩く人達 • それぞれがどのような設計パターンで書かれているの かを分類できるため、プロジェクトに後入りした場合でも 「そのプロジェクトのルール（パターン）」に乗りやすくな るのでは
- 10. 読んでいく
- 11. 読み進め方 • 1部:概論と2部:パターンの二部構成 • 概論を先に読み、パターンは流し見て必要になったと きに読み込む • 概論：パターンの章立てが1:1対応していないのでちょっと読 みにくいが、目次を見れば大体何の話をしたいかは分かる はず • 概論はどれも大事な概念や問題に集中しているので、 読み飛ばさないで読み込むのがよさそう • 逆にパターンの方はイマドキはフレームワークがやってたり する機能も多く、読み飛ばして良さそうなものもある
- 12. 本書の構成 • 概論 • レイヤ化 -> 全体 • ドメインロジックの構築 • リレーショナルデータベース へのマッピング • Webプレゼンテーション • 並行性 • セッションステート • 分散ストラテジー • まとめ • さまざまなパターン • ドメインロジックパターン • データソースのアーキテク チャに関するパターン • オブジェクトリレーショナル振 る舞いパターン • オブジェクトリレーショナル構 造パターン • オブジェクトリレーショナルメタ データマッピングパターン • Webプレゼンテーションパター ン • 分散パターン • オフライン並行性パターン • セッションステートパターン • ベースパターン この辺は「その他」みたいな雰囲気に見える
- 13. 今回は • 「はじめに」に相当する部分を紹介 • 本題に入る前の部分だが、本書の想定スコープや用語 定義が書かれているのでとても大事 • 目次 • アーキテクチャ • エンタープライズアプリケーション • エンタープライズアプリケーションの種類 • パフォーマンスに関する考え
- 14. アーキテクチャ • 「アーキテクチャ」って色々な人がいろんな意味で重要 そうに使うけど、人によって意味が違ってるよね・・・ • とはいえ以下はみんな同意してくれるよね • システムを部品に分割してブレークダウンするときの最上位 の概念である • 一度決定すると変更が困難であること • 本著では「設計」と「アーキテクチャ」の境目がどこにあ るのか、という話はしないことにするよ。きっとそれは 主観的な話だしね • 注: 原著との用語対応 • design: 設計 • architecture: アーキテクチャ
- 15. エンタープライズアプリケーション（1） • 「エンタープライズアプリケーション」とは？ • 給与計算・診療記録・出荷管理・コスト分析・信用調査・ 保険・会計・顧客サービス・外国為替取引など • 複雑なデータ、論理的とは限らないビジネスルールを 扱う • 「エンタープライズアプリケーション」でないもの • 自動車用燃料噴射制御・ワープロ・エレベータ制御・化 学プラント制御・電話交換・OS・コンパイラ・ゲーム
- 16. エンタープライズアプリケーション（2） • データに着目した特徴 • 永続的データを扱う • 年単位で記録・保存・参照される • 途中でデータ構造が変わったりもする • アプリケーション間での移行が発生したりする • とてもたくさんのデータを扱う • 数千万件程度は珍しくない • いまどきは通常データベースを使う • 同時アクセスされる • C/Sシステムのため、数人〜数百・数万規模の同時アクセスを扱 う • 数多くの画面で構成される • 扱うデータごとにも違うし、同じデータに対しても目的ごとに異なる UIを持ったりする
- 17. エンタープライズアプリケーション（3） • 他のエンタープライズアプリケーションと統合・連 携する • 連携方法もさまざま。ファイル連携やメッセージングな どなど • ビジネスプロセスとデータ概念の不一致がある • 現実世界のビジネスルールと論理的に扱いたいソフト ウェアの間に常にジレンマがある • （ソフトウェア）ロジック的におかしいやり方も、ビジネス 側の要求として受け入れなければいけない • ※そして大抵そういうところは大きな収益を上げていたりする
- 18. エンタープライズアプリケーション（4） • エンタープライズアプリケーション≒大規模システ ム • 大規模なものと思いがちだが、そういうわけでもない • むしろ筆者はアーキテクチャとプロセスを単純化して大 規模プロジェクトを小規模化することで、小規模システ ムの利点にも着目している • 小規模システムの方がダウンしても損害は少なかったりする
- 19. エンタープライズアプリケーションの種類（1） • 様々な種類があり、問題が異なればやり方も異なる。設計 時には代替案をいくつか考えておくことが大事である • 例 • B2C小売りWebシステム • ユーザが増えた際のハードウェア拡張性が必要 • アプリケーションのドメインロジックはわかりやすい • リース契約処理の自動化システム • ユーザ数は少ない • アプリケーションドメインロジックはとても複雑になる（月々のリース料計 算、期限前返品、予約時のデータチェックなど） • 小規模な会社の経費管理システム • ユーザは少ない • ロジックもシンプル • とても短期間で作る必要があり、ユーザ要求に従ってシステムへの機能 追加が必要になる（支払方法の追加、レポーティングなど）
- 20. エンタープライズアプリケーションの種類（2） • あるアプリケーションで使ったアーキテクチャを他 のアプリケーションに応用してもメリットが得られな いことがある • かといって、システムに柔軟性を加えても、柔軟性を持 たせるために追加された複雑性によって、実際には将 来的にシステムを進化させることが難しくなり、利益を 得るのが遅れてしまう • 全ての例にマッチする1つのアーキテクチャはない • アーキテクチャの選択とは、それぞれのシステム固有 の問題を理解し、その理解に従って適切な設計を選択 しなければならない
- 21. パフォーマンスに関する考え（1） • アーキテクチャの決定の多くはパフォーマンスに関す るもの • ほとんどのパフォーマンス問題は実際に実行・測定して最適 化していくことが望ましい • 一方、後からの最適化ではどうにもならないアーキテクチャ 上の決定もある • パフォーマンスは実際の環境・設定で測定しなければ 妥当なアドバイスをすることができないため、本書のよ うなアーキテクチャ一般の話の中で議論するのは難し い • パフォーマンスを考慮して設計の採用/不採用を決めたが、 実環境で測定してみたらそんな考慮は不要だった、という ケースがままある
- 22. パフォーマンスに関する考え（2） • 本書で扱う用語定義（1） • レスポンス時間（response time） • システムが外部からのリクエストを処理するのに要する時間 • レスポンス性（responsiveness） • リクエストに対してどれだけ早く応答を返すか • 待ち時間（latency） • あらゆるリクエストに対してシステムが応答するのに必要な最小 の待ち時間 • スループット（throughput） • ある時間内にどれくらいの処理を行えるか。エンタープライズアプ リケーションではtps（transactions per sec.）が一般に使われる • 負荷（load） • システムにかけているストレスの量。例えばユーザ数で、他の指 標と合わせて「ユーザー数10人の場合、レスポンス時間は0.5秒」 みたいな使い方をする
- 23. パフォーマンスに関する考え（3） • 本書で扱う用語定義（2） • 負荷感度（load sensitivity） • レスポンス時間が負荷によってどれくらい影響を受けるか • 負荷に対してより悪化の割合が大きい場合「劣化 （degredation）」という用語を使用する • 効率性（efficiency） • パフォーマンス / リソース • 容量（capacity） • 最大負荷、又は最大スループット
- 24. パフォーマンスに関する考え（4） • 拡張性（scalability） • リソース（通常はハードウェア）追加がパフォーマンスに 影響するか • 例: CPUを2倍にするとスループットは20tps増加する • 垂直拡張性（vertical scalability） • 別名スケールアップ（scaling up）。サーバ1台あたりのリソース を増やす • 水平拡張性（horizontal scalability） • 別名スケールアウト（scaling out）。サーバの数を増やす
- 26. パターン（1） • パターンは「繰り返し発生する一つ以上の問題に 対して共通かつ効果的に対処する」もの • パターンは現実に根ざしているので、解決策の核 （core of solution）を捜すために人の行動や物事の 動き方を観察する必要がある • 難しいことだが、見つけられればとても有用である • 我々にとって必要なのは以下であるので、パター ン詳細について全て細かく覚える必要はない • どんなパターンがあって • どんな問題を解決して • どうやって問題を解決するか
- 27. パターン（2） • パターンを見つけても、闇雲に適用すると死ぬ • 世の中にはパターンツールというものがあるようだが、 そういうのを使うとやりがち • パターンそのものはあくまで「生焼け（half baked）」 であり、適用する際には自分のプロジェクトごとに 焼き上げる必要がある
- 28. パターン（3） • 各パターンは比較的独立しているが、分離してい るというわけではない • 本書ではできるだけパターンを分割し、独立した状態に しようとしている（解説注: これが正に「生焼け」であるこ との要素だと思われる） • パターンは新しいもの（発明する）ではなく、すでに ある中から発見するもの • パターンに名前を付けて設計者やチーム内での語彙と して使える用にすることが大事
- 29. パターン（4） • 本書における「パターン」の構成 • パターン名 • 目的: 2〜3行の要約 • スケッチ: 主にUML図 • 問題の解説 • 動作方法 • 使用するタイミング • 参考文献 • サンプルコードなどはあるが、あくまでエラー処理など を除いた「生焼け」なものなので、動作可能なソース コードとして公開はしない方針
- 30. パターン利用に関する制限 • パターンの集合がエンタープライズアプリケーショ ン開発のガイドとはならない • 本書のパターンも著者が現場で目にしてきたパ ターンではあるが、ソフトウェアは何事も常に変化 するのでこれが完全なモノではないよ • パターンの使用は終点ではなく出発点である • 「生焼け」のパターンは我々自身が取り組むプロジェク トに適用する中で焼き上がるのだ（意訳）
- 31. まとめ • 本書の概要＆at a glance紹介 • 読者ターゲット層と刺さりそうな読者・前提知識の まとめ • 「はじめに」相当部分の解説 • 次回からは概論を順番にやっていきつつ、関連す るパターンをいくつか紹介しようかなと思います