- SlideBoom

ソフトウェアアーキテクチャ
の求め方
株式会社 gloops CTO室
Microsoft MVP for Visual C#
尾上雅則
0-1.自己紹介
• 尾上雅則 (おのうえまさのり)
• 株式会社 gloops CTO室
• 「大戦乱!! 三国志バトル」開発チーム → 現部署へ
• Microsoft MVP for Visual C# (2012/7~2014/6)
• RIAアーキテクチャ研究会
• Livet Author http://ugaya40.net/Livet
• Blog : http://ugaya40.net
• Twitter : @ugaya40
• Facebook : http://facebook.com/ugaya40
0-2.Agenda
1. 結局何を決めなきゃいけないのか？
2. 設計パターンを用いた分離
3. 実際の分離で使用する視点の例
4. まとめ
1.結局何を決めなければいけないのか？
ソフトウェアアーキテクチャとは？
そもそもアーキテクチャとは？
• アーキテクチャという言葉の定義に「万人の合意」は存在しな
いものとされる。
• それにも関わらず何故多くの開発者にとっての関心事として挙
げられるのか？
ソフトウェア設計は人間が無手で挑むには「複雑すぎる行為」だから
アーキテクチャ設計とは「ソフトウェア開発に関わるすべての複雑さ
への対処」のこと(と仮に定義する)
「複雑さ」へのアプローチ
• 複雑とは？
• 物事の事情や関係がこみいっていること。入り組んでいて、簡単に理
解・説明できないこと。一面的ではないこと。また、そのさま。
- デジタル大辞泉 http://kotobank.jp/word/%E8%A4%87%E9%9B%91
ソリューションは当たり前の事だけれども整理・細分化
工学的には「関心事の分離」
ソフトウェア工学に限らず、他の工学分野でも重要な設計思想とされて
いる
アーキテクチャ設計という作業
• 「関心事の分離」 = 「複雑で大きすぎる問題を小さく分解す
ると解決が容易になる」という考えに基づく
あらゆるプログラミングパラダイムや設計パターンと呼ばれる
もの、開発スケジュールの管理手段・工程分割の概念は「関心
事の分離」の実践に手を貸すもの
アーキテクチャ設計とは「様々な視点で関心事の分離を繰り返
し、解決容易なサイズにソフトウェア開発を分解していく作
業」と定義できる
ではソフトウェアアーキテクチャ設計は？
• アーキテクチャ設計
• ソフトウェア開発に関わるすべての複雑さへの対処
• 様々な視点で関心事の分離を繰り返し、解決容易なサイズにソフト
ウェア開発を分解していく作業
• ソフトウェアアーキテクチャ設計
• 様々な視点で関心事の分離を繰り返して開発目標となるソフトウェア
を分解し、開発や運用が容易な大きさの集合に開発目標を変えていく
作業(まだ結論ではない)
分離された関心事はどうあるべきか？
ソフトウェアアーキテクチャにおいて、分離された関心ごとが満
たすべき特性は？
モジュール化
いわゆる部品化。同一の関心事(その基準はその関心事の分離を行った
視点による)同士をいくつかまとめてシステムを構成する部品にする
(部品と言っても再利用できる云々などという考えは含まない)
カプセル化
モジュール(部品)が、単一モジュール内での機能同士のやり取りを隠
蔽していて、その外からはモジュールの内部を意識せずに利用できる
関心事の分離を行う代表的な視点
製品選定
開発プロセスに対する配慮
設計パターン
言語パラダイム
ソフトウェアアーキテクチャ設計
• アーキテクチャ設計
• ソフトウェア開発に関わるすべての複雑さへの対処
• 様々な視点で関心事の分離を繰り返し、解決容易なサイズにソフト
ウェア開発を分解していく作業
• ソフトウェアアーキテクチャ設計
• 様々な視点で関心事の分離を繰り返し、開発目標となるソフトウェア
をカプセル化されたモジュールに分解し、開発や運用が容易な大きさ
の集合に開発目標を変えていく作業
1章の最後に
アーキテクチャから、ソフトウェアアーキテクチャにフォーカス
しても非常に多くの知見(視点)が必要になる。
個人で果たしてすべてを網羅できるのか？それはきっと中国拳法
を一人ですべて(ry
ひとつのソフトウェアに対して行われた関心事の分離すべてを今
例示するのは不可能ですし、話す私の知見が足りず参考にならな
いところもあると思います。次章では私の専門である設計に
フォーカスした分離を見てみます。
2.設計パターンを用いた分離
設計パターンにフォーカスした関心事の分離の例
はじめに
• 設計パターンといわれるものは、よく必要がないといわれてい
たり誤解されていたり、学ぶ意欲があってもその本質がなかな
つかまれにくいものです。その理由は私は以下の１点に尽きる
と思っています。
各種用語の誤認と不理解なまま発信されたひどい情報の氾濫
詳細は例の中で随時
設計パターンは何でわかりにくいの？
• 「関心事の分離」のためと言われてもねぇ・・。
• サンプルコード出さないと解らない
• パターンであるなら、
• なぜどのアプリケーションでも決まった実装に収まらない
の？
• なぜ小さなアプリでは必要のないものなの？
設計パターンは何のためにあるの？
• アプリケーションにはいろいろな形(要件・要求)があります。
「関心事の分離」を行った後の分離された数・形は当然それぞ
れ異なるものになります。
アプリケーション
アプリケーション
アプリケーション
設計パターンは何のためにあるの？
• 対象のアプリケーションが十分小さかったり単純ならば
アプリケー
ション
アプリケーション
「複雑さへの対処」である「関心事の分離」を行う = この場合
は設計パターンを考慮する動機がありません。
設計パターンを用いた分離
 MVC系
アプリケーション
Presentation
Repository
 Repository
Pattern
設計パターンを用いた分離
 MVC系
アプリケーション
Presentation
Repository
例えばこんな分割、どこが設計パターンといわれる部分でしょうか？
 Repository
Pattern
設計パターンを用いた分離
• オレンジ色の矢印で示された一刀一刀、関心事を分離する視点
そのものがいわゆる設計パターンです。切った(分離した)結果
が設計パターンではないのです。
アプリケーション
Presentation
Repository
設計パターンを用いた分離
• よく見かける設計パターンに配慮したサンプルコードから設計
パターンの本質をつかもうとする事は
元の形もわからない、こういう断片から一刀一刀の狙いや視点を見極
めようとする事 = 無理
設計パターン・・・・？
• パターンは日本語では、「型」を表す言葉ですよね。英語
Patternには違う意味があるのかと思って調べたんですがあま
り違いませんでした。
• GoFのデザインパターンは結果がいつも同じになり確かにあれ
は「型」をあらわしていると思います。
• しかしいわゆる設計パターンは本当にパターンなのでしょう
か？
設計パターン・・・・？
• Patterns of Enterprise Application Architecture(PoEAA)が
パターンって言っちゃったから？
• もしこの概念が輸入されてくる際、「設計視点」という言葉が
当てられていたらこんな混乱は生まなかったのではないでしょ
うか？
• 「設計視点」であるならば、「MVCを適応する」ではなく
「MVCを考慮する」と適切に読まれていたはずです。
まとめ
• 設計パターンという言葉は害悪
• 混乱した際は設計視点として考えると、すっきりと答えが出る
と思います。
• 視点の具体例は次章にて
3.実際の分離で使用する視点の例
分離に使う知見の例
最初のステップ
これ
アプリケーション
Presentation
最初のステップ
• 多くの場合、GUIプラットフォームは最初に決まってしまうと
思います。「その視点で関心事の分離ができる」事を知ってい
れば最初の分離が適います。
• それがPresentation Domain Separation(プレゼンテーション
とドメインの分離以後PDS)です。これはみんな当たり前だ
と思っているようで実は大変誤解を受けている概念です。
Presentation Domain Separation
• 「見た目と構造の分離」？「プレゼンとドメインの分離」？
• 大変な誤解です。一見もっともらしく聞こえますが情報量がありませ
ん。
• どうして分離したいの？
• 分離したら楽になるからですよね？
• その根本動機は「多くの場合プレゼン部分は他の部分のコードと別の
知識が必要になり、別の制約がかかるから」です。
• C#を知っていてもXAMLを知らなければWPFアプリは書けません。
Presentation Domain Separation
• 次の入力フォーカスはどこになるのか、結構ルールが複雑だけ
ど、Presentation側に書くべきでしょうか？Domain側で書く
べきでしょうか？
• 「見た目と構造の分離」と考えていると？
• きっとPresen側に書くでしょう。そうしたことでPresenプラット
フォーム固有知識と関係ないコードが混ざってきてしまって、せっか
く行ったつもりの分離が結局不成立になります。
• 適切に考えるなら？
• Domain側で次のフォーカスはどこなのか決定し、Presen側は対応し
たPresen部品にフォーカスを移せばよいだけです。
Presentation Domain Separation
• 多くの方が違和感を覚えたのではないでしょうか？
• 違和感を覚えた方はぜひこちらのスライドをご覧ください。今
日の前章までの知識とあわせて完璧に理解できると思います。
そしてMVCAみたいなものがありえないという事もわかるはず
です。MVC系がどこにバインドした視点なのか。これをしっか
りと理解すれば必ずMVC系を使いこなせます。
• GUIアーキテクチャパターンの基礎からMVVMパターンへ
• http://www.slideboom.com/presentations/591514
Presentation Domain Separation
アプリケーションはそもそもドメイン(問題領域)に対するソ
リューションである。
そしてそのうちの一部分をPresentationPlatformが便利に
担ってくれている。
しかし便利に担ってくれている分、プレゼンテーションプ
ラットフォームは固有の知識や事情を必要とする部分がある。
そこを分離する
PDSとは、アプリケーション全体から
「PresentationPlatform関連」を分離する「視点」
残りの部分
赤い矢印
アプリケーション
Presentation
残りの部分
• PDS後の残りの部分を分解しようと思ったときに最初に考慮事
項に挙がるのがDomain Logic Patternです。
• PDS後の、プレゼンコードと関係ないJavaやObjective CやC#
だけで構成される部分の一番大きな切り方です。
• Domain Logic Patternはアプリケーションの状態の持ち方の
特性で大きく分かれます。
Domain Logic Pattern
代表例２つ
• TransactionScript
• 主にWebアプリ
• Domain Model
• 主にリッチクライアント
Transaction Script
• Transaction Script
Presentation
DomainModel
• DomainModel
Presentation
Domain Logic Pattern
この辺についても詳細に説明する時間はありません。
詳しく知りたい方はこちらをご覧ください
• Modelの中身ードメインロジックパターン
http://www.slideboom.com/presentations/591534
• きちんと理解すればTrasanctionScriptが有用な場面ではDRY
原則は原則ともいえない事や、選ぶ事でさらにリポジトリパ
ターンを使おうとした場合のメリットの変化などが理解できる
はずです。
まとめ
もちろん紹介した２ステップだけで完成するソフトウェアは少な
いでしょう。まだ大きな塊を、さらに粒度の小さい関心事分割の
視点を適用して、アプリケーションを分解していくことが必要で
す
最低限理解していただきたいのは、この章の冒頭のアニメーショ
ンでお見せした「大きな食べ物を順々に切り分けていく感覚」で
す。前のステップでの切り方によって、次のステップの切り方は
当然かわってきたりします。この感覚を理解すれば設計パターン
は怖くないでしょう。
まとめ
アーキテクチャ
• アーキテクチャ設計
• 様々な視点で関心事の分離を繰り返し、解決容易なサイズにソフトウェア開
発を分解していく作業
• ソフトウェアアーキテクチャ設計(上の細分化でしかない)
• 様々な視点で関心事の分離を繰り返し、開発目標となるソフトウェアをカプ
セル化されたモジュールに分解し、開発や運用が容易な大きさの集合に開発
目標を変えていく作業
• すべては「関心事の分離」に通ず
設計パターン
• 設計パターンも当然「関心事の分離」に向かうもの
• 設計パターンって言葉良くないよ！
• そのままでは口に入らない大きさ・変な形のパンケーキを順々
に切り分けていく感覚が、設計パターンの適応。
• もう設計パターンじゃなくて設計視点って言いません？
大体いつも使う知見
• PDS
• すべてのMVC系の裏にはこの概念があります。
• Domain Logic Pattern
• ここはなかなか難しいので、もっとうまくセッションで伝えられる手
段を模索しています。
• でもgloopsに入社して頂ければがっつり話込めますし、実際何人かの
エンジニアには理解していただいていますよ！
最後に
• 今日やってきた事・紹介したURLの２スライドでしていること
は結局「なぜそうしたいのか？」「なぜこれが必要になったの
か？」から、その言葉の意味を考え直しているだけです。
• 実際ただこれだけの事が、誤った情報の氾濫と「先入観」とそ
の微妙な名前によってなかなか理解できないのです。
• 筋の悪い言葉’s
• ASP.NET MVCのViewModel / DDD的なDomainModelとPoEAA的な
DomainModel/設計パターン / コードなきゃわかんない
最後に
• どこにも載っていない情報は自分で到達するしかありません。
• ソフトウェア開発で難しい概念とぶち当たった時、このスライ
ドの事を思い出していただけると幸いです。

Download Report