Architecture driven development のすすめ
•
12 likes•3,419 views
2015/08/07 第10回.NET勉強会@SANSAN 「Architecture Driven Development (ADD) のすすめ（仮）」 ADD について解説。 福井 厚 (@afukui)
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Architecture driven development のすすめ
Similar to Architecture driven development のすすめ (20)
More from Atsushi Fukui
More from Atsushi Fukui (11)
Architecture driven development のすすめ
- 1. Architecture Driven Development (ADD)の すすめ（仮） 福井 厚 Atsushi Fukui 第10回 .NET勉強会 2015.8.7
- 2. 本セッションの内容について 本セッションの内容は、発表者個人の経験に基づく個人的 な意見であり、所属する団体、組織の公式な見解、発表で はありません。 従って、本セッションの内容はその正しさをなんら保証す るものではないことをご承知おきください。 本セッションにて提示されるグラフ等で出展の明記のない ものは福井のこれまでの経験に基づく感覚的なものであり、 数値的な根拠はありませんのでご注意ください。
- 3. 自己紹介 福井 厚 （ふくい あつし） @afukui メーカー系サポートでOS、言語などを担当後、ソフト開発会社でC/S型業 務パッケージ、C/C++用ライブラリ等の開発を経験。94年にSIerへ転職し データベース設計支援、COM+による分散フレームワークの開発などを担 当。外資系SIerに転職しソリューションアーキテクトとして.NETによる企 業向けフレームワークの構築などを担当。2011年3月株式会社アークウェ イに入社、プリンシパル コンサルタントとして企業向けコンサルティング を行う。 2015円7月よりアマゾンデータサービスジャパン株式会社でSolutions Architect として活動。 2008年8月、Microsoft Certified Architect for Solutions Certification (MCA) に認定される。 マイクロソフトMVPアワード受賞歴11回（2015年7月にMVP 終了）
- 4. 個人ロール年表 1980 1990 2000 2010 カスタマサポート フィールドSE ソフトウェア デベロッパー 純国産システムエンジニア 外資系 アーキテクト 開発 コンサルタント クラウド ソリューショ ンアーキテクト
- 5. アジェンダ コンテキスト ソフトウェア開発における仕様変更のインパクト アジャイル開発のメリット あるアジャイル開発プロジェクトのベロシティ コスト エスカレーション アーキテクチャの作り方 アーキテクチャの変遷 まとめ
- 6. コンテキスト 本セッションのテーマ ソフトウェア開発におけるアーキテクチャの重要性 用語（アーキテクチャ） このセッションではアーキテクチャを主にソフトウェア アーキテ クチャの意味で使っています。 対象 企業向けアプリケーション開発を行っているアーキテクト、設計者、 開発者
- 7. お詫び DDDの話は（ほとんど）しません .NET の話は（ほとんど）しません お笑いネタがありません
- 8. Eric Evens の DDD におけるアーキテクチャ の位置づけ 要求をモデルにマップしたドメイン ルールエンジンなどオブジェ クトでないもの ファクトリなど特殊な 責務のオブジェクト 平べったいRDBの世界 インフラストラクチャ
- 13. 変更の痛みはコストであり生産性に影響 アジャイル開発でも変更のコストが大きいものがある レイヤリング スケーラビリティ ユーザビリティ セキュリティ データベース スキーマ コストが大きいと生産性に影響 作り直しの無駄が発生
- 14. あるアジャイル開発プロジェクトのベロシティ Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 非機能要件の見直し
- 16. アーキテクチャの作り方
- 17. アーキテクチャとは ISO/IEC/IEEE 42010（IEEE 1471改定版） http://www.iso-architecture.org/ieee-1471/cm/
- 19. アーキテクチャ ≠ フレームワーク フレームワークを利用することがアーキテクチャを作るこ とではありません 目的と制約に従って必要な品質特性を満たすソフトウェア の構造を定義し共通利用する機能を提供するものがアーキ テクチャ 従って目的と制約が異なれば違うアーキテクチャが必要です。
- 21. アーキテクチャ要求定義 目的の整理 アーキテクチャを構築する目的は何か ステークホルダーごとに要求は異なる アーキテクチャが解決すべき課題は何か 満たすべき品質特性 重視するソフトウェアの品質特性は何か 制約 組織、環境、過去の資産、開発者のスキル、政治的なしがらみなど、 どのような制約があるか 利用技術の選定 長く使える技術を見極める
- 22. ソフトウェア品質特性 ISO/IEC 25010（IEEE9126 の改定） どの品質特性と副特性を重視するか © 2015 iso25000.com
- 23. フィーチャーの抽出 目的に従ってアーキテクチャが提供すべきフィーチャーを 抽出 オプションとマンダトリの整理 フィーチャーと品質特性のマッピング 抽出したフィーチャーで重視する品質特性を満たしている かを確認する
- 24. 実装検証 抽出したフィーチャーがアーキテクチャ要求を満たしているこ とを検証 セキュリティ 想定されるケースでの認証、認可は必須 パフォーマンス パフォーマンスは測るまで誰にも分らない 限界点を知る システムにとって最も難しい機能から検証する クラウドの新機能活用や新しい認証基盤の利用など、過去にやったこ とがないものは失敗するかもしれないことを前提に必ず検証する
- 26. HOST / Dumb Terminal HOSTDumb Terminal Compute Build UI Display /Input Data State Narrow band network
- 27. Client / Server ServerClient Compute Build UI Display /Input Data State Local Area Network Compute
- 28. Web N-Tier Intranet Web Server / App Server Browser ComputeBuild UIDisplay /Input DataState Compute DB Server Auth Local Area Network
- 29. Internet Web / Multi Device Web/API Server Browser / Mobile Compute Build UI Display /Input Data State Compute DB Server Auth Auth Provider Internet
- 30. Micro Service Architecture Web/API Server Browser / Mobile Compute Build UI Display /Input Data State Compute DB Server Auth Auth Provider Internet Web/API Server DB Server Web/API Server DB Server
- 31. Cloud Native API Gateway Browser / Mobile / IoT Compute Build UI Display /Input Data State Compute RDB / NoSQL/ Big Data Analysis / ML Auth Service APIs Service APIs Auth Provider Internet
- 32. まとめ 変更に柔軟に対応できるアジャイル開発であっても変更のイン パクトが大きいものがある アーキテクチャを事前に構築することで、その後のイテレー ション開発で品質と生産性を大きく向上させることができる アーキテクチャは容易には変更できないことを肝に銘じて長い スパンで利用できる技術を選択する アーキテクチャの変更には理由がある。流行っているという理 由で選択しない
- 33. Q & A
- 34. ご清聴ありがとうございました