2014年12月20日のDevLove関西で使用したスライド

1. ゆらぎのある決定
グロースエクスパートナーズ（株）
ITアーキテクト 和智 右桂
DevLove Kanai 2014.12

2. 和智 右桂
JavaEE勉強会 所属
グロースエクスパートナーズ株式会社 勤務
Yukei Wachi
@digitalsoul0124
Digital Romanticism
http://d.hatena.ne.jp/digitalsoul
ネコ好き
Photo by @digitalsoul0124 All rights reserved.
IT アーキテクト

3. 時々翻訳をしています
Coming
Soon !

4. •導入
•事前に決めるべきこと
•まとめ
アジェンダ
Photo by @digitalsoul0124 All rights reserved.
スライド中で使用されている画像について、
その著作権の全部または一部は、 クレジットに示した著者によって保留されています。

5. 導入

6. アーキテクチャとは静的な構造？
https://www.flickr.com/photos/prasad-om/9840576823

7. プロダクトとチームは切り離せない
https://www.flickr.com/photos/statuelibrtynps/62767579

8. アジャイルにおける事前の決定とは？
https://www.flickr.com/photos/weesen/5564647782

9. 変化を受け入れる
• 最初にすべてを決めるわけではない
• 変化をどのように受け入れるかは、
最初に決めなければならない
完全な最終形は描けない

10. 事前に
決めるべきこと

11. https://www.flickr.com/photos/92334668@N07/11122773785
何を決めるべきなのか？

12. システムドメイン
プロセス

13. ドメイン

14. ドメインとは
• システムが対象とする業務領域
• ビジネスモデルとその実現フローの
存在が前提
• ビジネスモデルの策定とはまた
別の活動

15. やるべきこと
• スコープ策定
• アクター抽出
• ドメインの境界策定
• モデリング

16. いわゆる「機能」との違い
• いわゆる機能一覧も必要だが、目的
はどちらかというと「見積もり」あ
るいは「インデックス作り」
• 画面／帳票／バッチ
• ドメインの方は関係性が重要
• 境界／関係

17. ドメイン駆動設計について

18. ポイント
• ユーザーのドメイン知識およびメン
タルモデルに従うモデリングが重要
• ユーザーから学び、ユーザーに
フィードバックする
• 実装形式にこだわりすぎない方がよ
さそう
• レイヤリングは常に重要

19. ドメイン抽出の契機

20. 基本は高凝集・低結合
•外圧：顧客の視点から
•内圧：開発者の視点から

21. 目的の違い
「サマリーレベル」（雲ま
たは凧）のユーザーゴール
広告 注文 請求
広告を
作る
広告を
参照する
注文する
請求書を
作る
請求書を
送る
Alister Cockburn Writing Effective Use Cases Addison-Wesley 2001 p.62
外圧

22. 発芽
業務上重要な概念が
ある程度の粒度に成長する
航海
積載量
貨物
サイズ
*
仕様書
ドメインモデル
ソースコード
<script
var a=
var xl
if(xls
10 %のオーバーブッキングを認める
// 貨物を追加する
int 予約済み貨物量 = …
if(オーバーブッキングポリシー.allows(貨物, 航海)){
// 予約できない
return … ;
}
貨物予約ドメイン
オーバーブッキング
ポリシー
{貨物のサイズの合計 < 航海の積載量 * 1.1}
外圧

23. 横断的関心
業務的な関心が
複数のドメインにまたがる
広告
注文
請求
権限
外圧

24. 変化の可能性
特定の仕様が近い将来、
なんらかの理由で頻繁に
変化する可能性が高い
外圧

25. パラダイムの違い
E-Rモデルと状態遷移や
デシジョンテーブルなど
ER_Diagram http://www.flickr.com/photos/declankenny/4815835068/ by DeclanKenny
http://upload.wikimedia.org/wikipedia/commons/b/be/UML_state_diagram.png
内圧

26. 複雑度の違い 内圧
ドメインを実装していて
極端に仕様が複雑な場所が
発見される

27. システム

28. システムとは
• 技術カットでのいわゆる「アーキテ
クチャ」
• インフラアーキテクチャ
• ソフトウェアアーキテクチャ
• 実現方法

29. • フレームワーク
• モジュール分割方針
• 各種方式設計
やるべきこと
<script
var a=
var xl
if(xls
SQL
SQLテンプレート
パラメタ
結果セット
Search
Small Pop-Up
Pop-Up Menu
Small Combo
Combo Box
Bits
BobsThings
Stuff
OKCancel
Label
Ends
Odds
Help
Tag
Explanotext
A Very Nice Window Indeed
SIDEBAR
Search
Odds
Ends
UI
<script
var a=
var xl
if(xls
入力チェック
<script
var a=
var xl
if(xls
編集ロジック
データベース
DBアクセス

30. 機能追加の
コスト
ロジックの複雑度
トランザクションスクリプト
ドメインモデル

31. 基本はシンプルにhttps://www.flickr.com/photos/infomastern/14519782386

32. プロセス

33. プロセスとは
• システムをどのように開発していくか
• どのようなチーム構成になるか

34. やるべきこと
• スケジュール策定
• 工程定義
• 成果物定義
• チーム構成
つまりプロジェクトの組み立て

35. フィードバックループの確立https://www.flickr.com/photos/infomastern/14519782386

36. 要件
設計
実装
テスト
リリース
バリューストリーム
• 要件が形になるまでの流れ

37. 継続的デリバリーとは

38. バージョンコントロール
成果物リポジトリ
ソース
コード
環境&アプリ
設定
環境&アプリ
設定
コミットステージ
コンパイル
コミットテスト
アセンブル
コード分析
受け入れステージ
環境設定
バイナリデプロイ
スモークテスト
受け入れテスト
UAT
環境設定
バイナリデプロイ
スモークテスト
キャパシティステージ
環境設定
バイナリデプロイ
スモークテスト
本番
環境設定
バイナリデプロイ
スモークテスト
レポート
バイナリ
メタデータ
開発者
コードメトリクスと
テストの失敗を確認する
レポート
メタデータ
バイナリ
テスター
自分で
デプロイ
運用
ボタン1つで
リリース
バイナリ
レポート
メタデータ
デプロイメントパイプライン

39. 開発チーム
ユーザ
運用チーム
リポジトリ
CIサーバ
テスト環境
課題管理ツール
本番環境 エンドユーザ
システムをとりまく人の動き

40. スクラムとは

41. バリューストリームのフレームワーク

42. ステークホルダー
防火壁（4.2.9）
生産者（4.1.3）
顧客
開発者
アーキテクチャチーム（5.2.4）
アーキテクト
プロジェクトマネージャー
作業が内側に流れる（4.1.18）
ロールが生み出す情報の流れ

43. それぞれの関係

44. https://www.flickr.com/photos/4st4roth/2366615948
個別に考えられない

45. ドメインとシステムの関係

46. ソフトウェアアーキテクチャは
ドメインのパラダイムと無関係
ではいられない

47. ソフトウェアアーキテクチャの
境界はドメインの境界に従う

48. ドメインとプロセスの関係

49. チームの構成はドメインの構成
に従う

50. 変化の速度はドメインに応じて
異なる

51. システムとプロセスの関係

52. 成果物はソフトウェアアーキテ
クチャに従う

53. ソフトウェアアーキテクチャは
チームのスキルに制限される

54. 最初の方針に従い、
プロダクトとチームは成長する
https://www.flickr.com/photos/ervins_strauhmanis/14000932121

55. まとめ

56. • アーキテクチャはプロダクトとチー
ムの全体の方向性を規定する。
• ドメイン
• システム
• プロセス
• プロダクトとチームはアーキテクチャ
の定める方向に向けて、時間と共に
成長していく。

57. ありがとうございました！
Photo by @digitalsoul0124 All rights reserved.