Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ゆらぎのある決定

1,598 views

Published on

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

Published in: Technology

ゆらぎのある決定

  1. 1. ゆらぎのある決定 グロースエクスパートナーズ(株) ITアーキテクト 和智 右桂 DevLove Kanai 2014.12
  2. 2. 和智 右桂 JavaEE勉強会 所属 グロースエクスパートナーズ株式会社 勤務 Yukei Wachi @digitalsoul0124 Digital Romanticism http://d.hatena.ne.jp/digitalsoul ネコ好き Photo by @digitalsoul0124 All rights reserved. IT アーキテクト
  3. 3. 時々翻訳をしています Coming Soon !
  4. 4. •導入 •事前に決めるべきこと •まとめ アジェンダ Photo by @digitalsoul0124 All rights reserved. スライド中で使用されている画像について、 その著作権の全部または一部は、 クレジットに示した著者によって保留されています。
  5. 5. 導入
  6. 6. アーキテクチャとは静的な構造? https://www.flickr.com/photos/prasad-om/9840576823
  7. 7. プロダクトとチームは切り離せない https://www.flickr.com/photos/statuelibrtynps/62767579
  8. 8. アジャイルにおける事前の決定とは? https://www.flickr.com/photos/weesen/5564647782
  9. 9. 変化を受け入れる • 最初にすべてを決めるわけではない • 変化をどのように受け入れるかは、 最初に決めなければならない 完全な最終形は描けない
  10. 10. 事前に 決めるべきこと
  11. 11. https://www.flickr.com/photos/92334668@N07/11122773785 何を決めるべきなのか?
  12. 12. システムドメイン プロセス
  13. 13. ドメイン
  14. 14. ドメインとは • システムが対象とする業務領域 • ビジネスモデルとその実現フローの 存在が前提 • ビジネスモデルの策定とはまた 別の活動
  15. 15. やるべきこと • スコープ策定 • アクター抽出 • ドメインの境界策定 • モデリング
  16. 16. いわゆる「機能」との違い • いわゆる機能一覧も必要だが、目的 はどちらかというと「見積もり」あ るいは「インデックス作り」 • 画面/帳票/バッチ • ドメインの方は関係性が重要 • 境界/関係
  17. 17. ドメイン駆動設計について
  18. 18. ポイント • ユーザーのドメイン知識およびメン タルモデルに従うモデリングが重要 • ユーザーから学び、ユーザーに フィードバックする • 実装形式にこだわりすぎない方がよ さそう • レイヤリングは常に重要
  19. 19. ドメイン抽出の契機
  20. 20. 基本は高凝集・低結合 •外圧:顧客の視点から •内圧:開発者の視点から
  21. 21. 目的の違い 「サマリーレベル」(雲ま たは凧)のユーザーゴール 広告 注文 請求 広告を 作る 広告を 参照する 注文する 請求書を 作る 請求書を 送る Alister Cockburn Writing Effective Use Cases Addison-Wesley 2001 p.62 外圧
  22. 22. 発芽 業務上重要な概念が ある程度の粒度に成長する 航海 積載量 貨物 サイズ * 仕様書 ドメインモデル ソースコード <script var a= var xl if(xls 10 %のオーバーブッキングを認める // 貨物を追加する int 予約済み貨物量 = … if(オーバーブッキングポリシー.allows(貨物, 航海)){  // 予約できない  return … ; } 貨物予約ドメイン オーバーブッキング ポリシー {貨物のサイズの合計 < 航海の積載量 * 1.1} 外圧
  23. 23. 横断的関心 業務的な関心が 複数のドメインにまたがる 広告 注文 請求 権限 外圧
  24. 24. 変化の可能性 特定の仕様が近い将来、 なんらかの理由で頻繁に 変化する可能性が高い 外圧
  25. 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. 26. 複雑度の違い 内圧 ドメインを実装していて 極端に仕様が複雑な場所が 発見される
  27. 27. システム
  28. 28. システムとは • 技術カットでのいわゆる「アーキテ クチャ」 • インフラアーキテクチャ • ソフトウェアアーキテクチャ • 実現方法
  29. 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. 30. 機能追加の コスト ロジックの複雑度 トランザクションスクリプト ドメインモデル
  31. 31. 基本はシンプルにhttps://www.flickr.com/photos/infomastern/14519782386
  32. 32. プロセス
  33. 33. プロセスとは • システムをどのように開発していくか • どのようなチーム構成になるか
  34. 34. やるべきこと • スケジュール策定 • 工程定義 • 成果物定義 • チーム構成 つまりプロジェクトの組み立て
  35. 35. フィードバックループの確立https://www.flickr.com/photos/infomastern/14519782386
  36. 36. 要件 設計 実装 テスト リリース バリューストリーム • 要件が形になるまでの流れ
  37. 37. 継続的デリバリーとは
  38. 38.                バージョンコントロール 成果物リポジトリ ソース コード 環境&アプリ 設定 環境&アプリ 設定 コミットステージ コンパイル コミットテスト アセンブル コード分析 受け入れステージ 環境設定 バイナリデプロイ スモークテスト 受け入れテスト UAT 環境設定 バイナリデプロイ スモークテスト キャパシティステージ 環境設定 バイナリデプロイ スモークテスト 本番 環境設定 バイナリデプロイ スモークテスト レポート バイナリ メタデータ 開発者 コードメトリクスと テストの失敗を確認する レポート メタデータ バイナリ テスター 自分で デプロイ 運用 ボタン1つで リリース バイナリ レポート メタデータ デプロイメントパイプライン
  39. 39. 開発チーム ユーザ 運用チーム リポジトリ CIサーバ テスト環境 課題管理ツール 本番環境 エンドユーザ システムをとりまく人の動き
  40. 40. スクラムとは
  41. 41. バリューストリームのフレームワーク
  42. 42. ステークホルダー 防火壁(4.2.9) 生産者(4.1.3) 顧客 開発者 アーキテクチャチーム(5.2.4) アーキテクト プロジェクトマネージャー 作業が内側に流れる(4.1.18) ロールが生み出す情報の流れ
  43. 43. それぞれの関係
  44. 44. https://www.flickr.com/photos/4st4roth/2366615948 個別に考えられない
  45. 45. ドメインとシステムの関係
  46. 46. ソフトウェアアーキテクチャは ドメインのパラダイムと無関係 ではいられない
  47. 47. ソフトウェアアーキテクチャの 境界はドメインの境界に従う
  48. 48. ドメインとプロセスの関係
  49. 49. チームの構成はドメインの構成 に従う
  50. 50. 変化の速度はドメインに応じて 異なる
  51. 51. システムとプロセスの関係
  52. 52. 成果物はソフトウェアアーキテ クチャに従う
  53. 53. ソフトウェアアーキテクチャは チームのスキルに制限される
  54. 54. 最初の方針に従い、 プロダクトとチームは成長する https://www.flickr.com/photos/ervins_strauhmanis/14000932121
  55. 55. まとめ
  56. 56. • アーキテクチャはプロダクトとチー ムの全体の方向性を規定する。 • ドメイン • システム • プロセス • プロダクトとチームはアーキテクチャ の定める方向に向けて、時間と共に 成長していく。
  57. 57. ありがとうございました! Photo by @digitalsoul0124 All rights reserved.

×