ソフトウェアアーキテクチャの求め方

+6

No comments posted yet

Comments

Slide 10

最初は当然、必要用件を満たすテクノロジーが選択されなければならない 要員スキルだけを理由に本当にWindowsアプリを作るのにJavaを選ぶの?(言語) エクセルのスプレッドシートみたいなUIを実現したいのにXAMLテクノロジーを選ぶ?(UIプラットフォーム) 多くの場合そのテクノロジーが「向いていること」の対する知見は発見しやすいが、「向いていないこと」に関するまとまった情報を見つけるのはなかなか難しい 個人の開発でもウォーターフォールするの? 僕なんかプライベート開発では3回目に立てたソリューションが大体fixソリューション。それ以前のものは破棄。 仕様を決められない言い訳にアジャイル使っていない? いろんな人に恨まれるのでノーコメントで。 頻繁な仕様変更が予想されるのに自動テスト書けない設計にしちゃうの? リグレッションテストできる領域は広くとりましょうよ MVCとか冗長だって、本当にMVC・・・というか設計パターンの意味わかってる? Repository Pattern入れようとしたって、Domain LogicがTransaction ScriptベースかDomain Modelベースかで粒度・有用性ともに変わるよね? DRY原則に反したから何だって言うの? VB6得意なんで、C#初めてですがなんとかなるでしょ!(キリッ さようなら 私for文なら他の言語で知っているし、同じこと出来るんだからLINQとか覚えなくていいでしょ それがどれだけの工数とバグのリスクを生むのか解ってる? C#で生スレッド立てて、非同期 try – catchの入れ子がんばって書いた! それがどれだけの工数とバグのリスクを生むのか解ってる?

Slide 1

ソフトウェアアーキテクチャ の求め方 株式会社 gloops CTO室 Microsoft MVP for Visual C# 尾上 雅則

Slide 2

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

Slide 3

0-2.Agenda 結局何を決めなきゃいけないのか? 設計パターンを用いた分離 実際の分離で使用する視点の例 まとめ

Slide 4

1.結局何を決めなければいけないのか? ソフトウェアアーキテクチャとは?

Slide 5

そもそもアーキテクチャとは? アーキテクチャという言葉の定義に「万人の合意」は存在しないものとされる。 それにも関わらず何故多くの開発者にとっての関心事として挙げられるのか? ソフトウェア設計は人間が無手で挑むには「複雑すぎる行為」だから アーキテクチャ設計とは「ソフトウェア開発に関わるすべての複雑さへの対処」のこと(と仮に定義する)

Slide 6

「複雑さ」へのアプローチ 複雑 とは? 物事の事情や関係がこみいっていること。入り組んでいて、簡単に理解・説明できないこと。一面的ではないこと。また、そのさま。 - デジタル大辞泉 http://kotobank.jp/word/%E8%A4%87%E9%9B%91 ソリューションは当たり前の事だけれども整理・細分化 工学的には「関心事の分離」 ソフトウェア工学に限らず、他の工学分野でも重要な設計思想とされている

Slide 7

アーキテクチャ設計という作業 「関心事の分離」 = 「複雑で大きすぎる問題を小さく分解すると解決が容易になる」という考えに基づく あらゆるプログラミングパラダイムや設計パターンと呼ばれるもの、開発スケジュールの管理手段・工程分割の概念は「関心事の分離」の実践に手を貸すもの アーキテクチャ設計とは「様々な視点で関心事の分離を繰り返し、解決容易なサイズにソフトウェア開発を分解していく作業」と定義できる

Slide 8

ではソフトウェアアーキテクチャ設計は? アーキテクチャ設計 ソフトウェア開発に関わるすべての複雑さへの対処 様々な視点で関心事の分離を繰り返し、解決容易なサイズにソフトウェア開発を分解していく作業 ソフトウェアアーキテクチャ設計 様々な視点で関心事の分離を繰り返して開発目標となるソフトウェアを分解し、開発や運用が容易な大きさの集合に開発目標を変えていく作業(まだ結論ではない)

Slide 9

分離された関心事はどうあるべきか? ソフトウェアアーキテクチャにおいて、分離された関心ごとが満たすべき特性は? モジュール化 いわゆる部品化。同一の関心事(その基準はその関心事の分離を行った視点による)同士をいくつかまとめてシステムを構成する部品にする(部品と言っても再利用できる云々などという考えは含まない) カプセル化 モジュール(部品)が、単一モジュール内での機能同士のやり取りを隠蔽していて、その外からはモジュールの内部を意識せずに利用できる

Slide 10

関心事の分離を行う代表的な視点 製品選定 開発プロセスに対する配慮 設計パターン 言語パラダイム

Slide 11

ソフトウェアアーキテクチャ設計 アーキテクチャ設計 ソフトウェア開発に関わるすべての複雑さへの対処 様々な視点で関心事の分離を繰り返し、解決容易なサイズにソフトウェア開発を分解していく作業 ソフトウェアアーキテクチャ設計 様々な視点で関心事の分離を繰り返し、開発目標となるソフトウェアをカプセル化されたモジュールに分解し、開発や運用が容易な大きさの集合に開発目標を変えていく作業

Slide 12

1章の最後に アーキテクチャから、ソフトウェアアーキテクチャにフォーカスしても非常に多くの知見(視点)が必要になる。 個人で果たしてすべてを網羅できるのか?それはきっと中国拳法を一人ですべて(ry ひとつのソフトウェアに対して行われた関心事の分離すべてを今例示するのは不可能ですし、話す私の知見が足りず参考にならないところもあると思います。次章では私の専門である設計にフォーカスした分離を見てみます。

Slide 13

2.設計パターンを用いた分離 設計パターンにフォーカスした関心事の分離の例

Slide 14

はじめに 設計パターンといわれるものは、よく必要がないといわれていたり誤解されていたり、学ぶ意欲があってもその本質がなかなつかまれにくいものです。その理由は私は以下の1点に尽きると思っています。 各種用語の誤認と不理解なまま発信されたひどい情報の氾濫 詳細は例の中で随時

Slide 15

設計パターンは何でわかりにくいの? 「関心事の分離」のためと言われてもねぇ・・。 サンプルコード出さないと解らない パターンであるなら、 なぜどのアプリケーションでも決まった実装に収まらないの? なぜ小さなアプリでは必要のないものなの?

Slide 16

設計パターンは何のためにあるの? アプリケーションにはいろいろな形(要件・要求)があります。「関心事の分離」を行った後の分離された数・形は当然それぞれ異なるものになります。 アプリケーション アプリケーション アプリケーション

Slide 17

設計パターンは何のためにあるの? 対象のアプリケーションが十分小さかったり単純ならば 「複雑さへの対処」である「関心事の分離」を行う = この場合は設計パターンを考慮する 動機がありません。 アプリケーション アプリケーション

Slide 18

設計パターンを用いた分離 アプリケーション Presentation MVC系 Repository Repository Pattern

Slide 19

設計パターンを用いた分離 アプリケーション Presentation MVC系 Repository Repository Pattern 例えばこんな分割、どこが設計パターンといわれる部分でしょうか?

Slide 20

設計パターンを用いた分離 アプリケーション Presentation Repository オレンジ色の矢印で示された一刀一刀、関心事を分離する視点そのものがいわゆる設計パターンです。切った(分離した)結果が設計パターンではないのです。

Slide 21

設計パターンを用いた分離 よく見かける設計パターンに配慮したサンプルコードから設計パターンの本質をつかもうとする事は 元の形もわからない、こういう断片から一刀一刀の狙いや視点を見極めようとする事 = 無理

Slide 22

設計パターン・・・・? パターンは日本語では、「型」を表す言葉ですよね。英語 Patternには違う意味があるのかと思って調べたんですがあまり違いませんでした。 GoFのデザインパターンは結果がいつも同じになり確かにあれは「型」をあらわしていると思います。 しかしいわゆる設計パターンは本当にパターンなのでしょうか?

Slide 23

設計パターン・・・・? Patterns of Enterprise Application Architecture(PoEAA)がパターンって言っちゃったから? もしこの概念が輸入されてくる際、「設計視点」という言葉が当てられていたらこんな混乱は生まなかったのではないでしょうか? 「設計視点」であるならば、「MVCを適応する」ではなく「MVCを考慮する」と適切に読まれていたはずです。

Slide 24

まとめ 設計パターンという言葉は害悪 混乱した際は設計視点として考えると、すっきりと答えが出ると思います。 視点の具体例は次章にて

Slide 25

3.実際の分離で使用する視点の例 分離に使う知見の例

Slide 26

最初のステップ アプリケーション Presentation これ

Slide 27

最初のステップ 多くの場合、GUIプラットフォームは最初に決まってしまうと思います。「その視点で関心事の分離ができる」事を知っていれば最初の分離が適います。 それがPresentation Domain Separation(プレゼンテーションとドメインの分離 以後PDS)です。 これはみんな当たり前だと思っているようで実は大変誤解を受けている概念です。

Slide 28

Presentation Domain Separation 「見た目と構造の分離」?「プレゼンとドメインの分離」? 大変な誤解です。一見もっともらしく聞こえますが情報量がありません。 どうして分離したいの? 分離したら楽になるからですよね? その根本動機は「多くの場合プレゼン部分は他の部分のコードと別の知識が必要になり、別の制約がかかるから」です。 C#を知っていてもXAMLを知らなければWPFアプリは書けません。

Slide 29

Presentation Domain Separation 次の入力フォーカスはどこになるのか、結構ルールが複雑だけど、Presentation側に書くべきでしょうか?Domain側で書くべきでしょうか? 「見た目と構造の分離」と考えていると? きっとPresen側に書くでしょう。そうしたことでPresenプラットフォーム固有知識と関係ないコードが混ざってきてしまって、せっかく行ったつもりの分離が結局不成立になります。 適切に考えるなら? Domain側で次のフォーカスはどこなのか決定し、Presen側は対応したPresen部品にフォーカスを移せばよいだけです。

Slide 30

Presentation Domain Separation 多くの方が違和感を覚えたのではないでしょうか? 違和感を覚えた方はぜひこちらのスライドをご覧ください。今日の前章までの知識とあわせて完璧に理解できると思います。そしてMVCAみたいなものがありえないという事もわかるはずです。MVC系がどこにバインドした視点なのか。これをしっかりと理解すれば必ずMVC系を使いこなせます。 GUIアーキテクチャパターンの基礎からMVVMパターンへ http://www.slideboom.com/presentations/591514

Slide 31

Presentation Domain Separation アプリケーションはそもそもドメイン(問題領域)に対するソリューションである。 そしてそのうちの一部分をPresentationPlatformが便利に担ってくれている。 しかし便利に担ってくれている分、プレゼンテーションプラットフォームは固有の知識や事情を必要とする部分がある。そこを分離する PDSとは、アプリケーション全体から「PresentationPlatform関連」を分離する「視点」

Slide 32

残りの部分 アプリケーション Presentation 赤い矢印

Slide 33

残りの部分 PDS後の残りの部分を分解しようと思ったときに最初に考慮事項に挙がるのがDomain Logic Patternです。 PDS後の、プレゼンコードと関係ないJavaやObjective CやC#だけで構成される部分の一番大きな切り方です。 Domain Logic Patternはアプリケーションの状態の持ち方の特性で大きく分かれます。

Slide 34

Domain Logic Pattern 代表例2つ TransactionScript 主にWebアプリ Domain Model 主にリッチクライアント

Slide 35

Transaction Script Transaction Script Presentation

Slide 36

DomainModel DomainModel Presentation

Slide 37

Domain Logic Pattern この辺についても詳細に説明する時間はありません。 詳しく知りたい方はこちらをご覧ください Modelの中身ードメインロジックパターンhttp://www.slideboom.com/presentations/591534 きちんと理解すればTrasanctionScriptが有用な場面ではDRY原則は原則ともいえない事や、選ぶ事でさらにリポジトリパターンを使おうとした場合のメリットの変化などが理解できるはずです。

Slide 38

まとめ もちろん紹介した2ステップだけで完成するソフトウェアは少ないでしょう。まだ大きな塊を、さらに粒度の小さい関心事分割の視点を適用して、アプリケーションを分解していくことが必要です 最低限理解していただきたいのは、この章の冒頭のアニメーションでお見せした「大きな食べ物を順々に切り分けていく感覚」です。前のステップでの切り方によって、次のステップの切り方は当然かわってきたりします。この感覚を理解すれば設計パターンは怖くないでしょう。

Slide 39

まとめ

Slide 40

アーキテクチャ アーキテクチャ設計 様々な視点で関心事の分離を繰り返し、解決容易なサイズにソフトウェア開発を分解していく作業 ソフトウェアアーキテクチャ設計(上の細分化でしかない) 様々な視点で関心事の分離を繰り返し、開発目標となるソフトウェアをカプセル化されたモジュールに分解し、開発や運用が容易な大きさの集合に開発目標を変えていく作業 すべては「関心事の分離」に通ず

Slide 41

設計パターン 設計パターンも当然「関心事の分離」に向かうもの 設計パターンって言葉良くないよ! そのままでは口に入らない大きさ・変な形のパンケーキを順々に切り分けていく感覚が、設計パターンの適応。 もう設計パターンじゃなくて設計視点って言いません?

Slide 42

大体いつも使う知見 PDS すべてのMVC系の裏にはこの概念があります。 Domain Logic Pattern ここはなかなか難しいので、もっとうまくセッションで伝えられる手段を模索しています。 でもgloopsに入社して頂ければがっつり話込めますし、実際何人かのエンジニアには理解していただいていますよ!

Slide 43

最後に 今日やってきた事・紹介したURLの2スライドでしていることは結局「なぜそうしたいのか?」「なぜこれが必要になったのか?」から、その言葉の意味を考え直しているだけです。 実際ただこれだけの事が、誤った情報の氾濫と「先入観」とその微妙な名前によってなかなか理解できないのです。 筋の悪い言葉’s ASP.NET MVCのViewModel / DDD的なDomainModelとPoEAA的なDomainModel/設計パターン / コードなきゃわかんない

Slide 44

最後に どこにも載っていない情報は自分で到達するしかありません。 ソフトウェア開発で難しい概念とぶち当たった時、このスライドの事を思い出していただけると幸いです。

URL: