Architecture DrivenDevelopment (ADD)の

すすめ（仮）

福井 厚 Atsushi Fukui

第10回 .NET勉強会

2015.8.7

本セッションの内容について

本セッションの内容は、発表者個人の経験に基づく個人的な意見であり、所属する団体、組織の公式な見解、発表ではありません。

従って、本セッションの内容はその正しさをなんら保証するものではないことをご承知おきください。

本セッションにて提示されるグラフ等で出展の明記のないものは福井のこれまでの経験に基づく感覚的なものであり、数値的な根拠はありませんのでご注意ください。

自己紹介

福井 厚 （ふくい あつし）

@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 終了）

個人ロール年表1980 1990 2000 2010

カスタマサポートフィールドSE

ソフトウェアデベロッパー

純国産システムエンジニア

外資系アーキテクト

開発コンサルタント

クラウドソリューションアーキテクト

アジェンダ

コンテキスト

ソフトウェア開発における仕様変更のインパクト

アジャイル開発のメリット

あるアジャイル開発プロジェクトのベロシティ

コストエスカレーション

アーキテクチャの作り方

アーキテクチャの変遷

まとめ

コンテキスト

本セッションのテーマ

ソフトウェア開発におけるアーキテクチャの重要性

用語（アーキテクチャ）

このセッションではアーキテクチャを主にソフトウェアアーキテクチャの意味で使っています。

対象

企業向けアプリケーション開発を行っているアーキテクト、設計者、開発者

お詫び

DDDの話は（ほとんど）しません

.NETの話は（ほとんど）しません

お笑いネタがありません

Eric Evens の DDD におけるアーキテクチャの位置づけ

要求をモデルにマップしたドメイン

ルールエンジンなどオブジェクトでないもの

ファクトリなど特殊な責務のオブジェクト

平べったいRDBの世界

インフラストラクチャ

システム

サービスA

今回お話すするアーキテクチャの位置づけ

アーキテクチャUIレイアウト、認証、認可、例外処理、入力検証、データアクセス、ロギングなど

サービスのデータ処理

サービスロジック

UI可変部

サービスB

サービスのデータ処理

サービス ロジック

UI可変部

サービスC

サービスのデータ処理

サービスロジック

UI可変部

ここ

ソフトウェア開発における仕様変更のインパクト

要求定義 設計 実装・単体テスト

結合・システムテスト

受け入れテスト 展開・本番稼働

アジャイル開発のメリット

ウォーターフォール開発

アジャイル開発の変更管理

短期間のスプリント化

変更の痛みはコストであり生産性に影響

アジャイル開発でも変更のコストが大きいものがある

レイヤリング

スケーラビリティ

ユーザビリティ

セキュリティ

データベーススキーマ

コストが大きいと生産性に影響

作り直しの無駄が発生

あるアジャイル開発プロジェクトのベロシティ

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8

非機能要件の見直し

Architecture Driven Development（ADD）とは

アーキテクチャを先に開発することで、その後のアプリケーション開発の品質と生産性を向上させるアーキテクチャ駆動開発方式のことである。

アーキテクチャの作り方

アーキテクチャとは ISO/IEC/IEEE 42010（IEEE 1471改定版）

http://www.iso-architecture.org/ieee-1471/cm/

アーキテクチャは階層構造 企業全体のアーキテクチャから実装コードまですべてがアーキテクチャ

アーキテクチャ ≠ フレームワーク

フレームワークを利用することがアーキテクチャを作ることではありません

目的と制約に従って必要な品質特性を満たすソフトウェアの構造を定義し共通利用する機能を提供するものがアーキテクチャ

従って目的と制約が異なれば違うアーキテクチャが必要です。

正しいアーキテクチャを構築するために

要求定義

フィーチャーの抽出

実装検証

アーキテクチャ要求定義

目的の整理

アーキテクチャを構築する目的は何か

ステークホルダーごとに要求は異なる

アーキテクチャが解決すべき課題は何か

満たすべき品質特性

重視するソフトウェアの品質特性は何か

制約

組織、環境、過去の資産、開発者のスキル、政治的なしがらみなど、どのような制約があるか

利用技術の選定

長く使える技術を見極める

ソフトウェア品質特性 ISO/IEC 25010（IEEE9126の改定）

どの品質特性と副特性を重視するか

© 2015 iso25000.com

フィーチャーの抽出

目的に従ってアーキテクチャが提供すべきフィーチャーを抽出

オプションとマンダトリの整理

フィーチャーと品質特性のマッピング

抽出したフィーチャーで重視する品質特性を満たしているかを確認する

実装検証

抽出したフィーチャーがアーキテクチャ要求を満たしていることを検証

セキュリティ

想定されるケースでの認証、認可は必須

パフォーマンス

パフォーマンスは測るまで誰にも分らない

限界点を知る

システムにとって最も難しい機能から検証する

クラウドの新機能活用や新しい認証基盤の利用など、過去にやったことがないものは失敗するかもしれないことを前提に必ず検証する

アーキテクチャの変遷ある視点で見たアーキテクチャの変遷と理由

HOST / Dumb Terminal

HOSTDumb

Terminal

Compute

Build UI

Display /Input

Data

State

Narrow band network

Client / Server

ServerClient

Compute

Build UI

Display /Input

Data

State

Local Area Network

Compute

Web N-Tier Intranet

Web Server /

App ServerBrowser

ComputeBuild UIDisplay /Input

DataState

Compute

DB Server

Auth

Local Area Network

Internet Web / Multi Device

Web/API Server

Browser

/

Mobile

Compute

Build UI

Display /Input

Data

State

Compute

DB Server

Auth

Auth Provider

Internet

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

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

まとめ

変更に柔軟に対応できるアジャイル開発であっても変更のインパクトが大きいものがある

アーキテクチャを事前に構築することで、その後のイテレーション開発で品質と生産性を大きく向上させることができる

アーキテクチャは容易には変更できないことを肝に銘じて長いスパンで利用できる技術を選択する

アーキテクチャの変更には理由がある。流行っているという理由で選択しない

Q & A

ご清聴ありがとうございました