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.

社内 DDD 勉強会 #4

142 views

Published on

社内で行った DDD 勉強会の第3回です。
DDD 本の第3部の話になります。

Published in: Software
  • Be the first to comment

  • Be the first to like this

社内 DDD 勉強会 #4

  1. 1. DDD勉強会 #4 SRA 産業第1事業部 鈴木真吾 @giantneco
  2. 2. 注意事項 • 発表資料は後で SlideShare にあげます
  3. 3. 今回の範囲 • 第1部 ドメインモデルを機能させる • 第2部 モデル駆動設計の構成要素 • モデルを分離するアーキテクチャ • 構成要素のパターン • ライフサイクルのパターン • 応用例 • 第3部 より深い洞察へ向かうリファクタリング • 第4部 戦略的設計
  4. 4. 今回の内容 • リファクタリング • 深いモデル • 発見のプロセス • しなやかな設計
  5. 5. リファクタリング リファクタリングとは • 機能を変更しないで行われるソフトウェアの再設計 • 技術的な観点でのリファクタリング • コードを読みやすくする • 詳細なレベルで機能を追加する • より”深いレベル”のリファクタリング • 深いモデルに到達する • ドメインについて新たな洞察を反映する • コードを通してモデルの表現を明確にする
  6. 6. 深いモデル • 明快な表現を提供する • ドメインエキスパートの主要な関心ごと • 最も深く関連した知識 • 例)輸送アプリケーション • 最初は船舶オブジェクトがあった • リファクタリングの結果「輸送機器の運行」という形に抽象化 • ドメインエキスパートの関心ごとが「貨物を配送する」という点にあったため
  7. 7. 発見のプロセス • 概念を掘り起こす • 文献を読む • 実験する
  8. 8. 発見のプロセス:概念を掘り出す 次の場合にはモデリングうまくできていないかもしれない • ユーザがいつもなにか一つのことについて話しているが、開発 者にはそれがなぜ必要なのかわからない • 何か複雑なものを簡潔に述べている単語がある • ドメインエキスパートに言葉の選び方を正された • 特定のフレーズを使ったときに、ドメインエキスパートを困惑 させた • ユーザ、ドメインエキスパートが設計にない用語を使用した
  9. 9. 発見のプロセス:文献を読む • ドメインにおいて自明なことを見逃さない • ドメインに関する文献をあたり、基本的な概念、社会通念を調 べる
  10. 10. しなやかな設計のためのパターン リファクタリングを恒常的に行うため、変更・使用を容易にする • 意図の明白なインターフェース • 副作用のない関数 • 表明 • 効果的な分解 • 概念の輪郭 • 独立したクラス • 閉じた操作 • 宣言的な設計 • アナリシスパターン • デザインパターン
  11. 11. 意図の明白なインターフェース • クラスと操作には、効果と目的を記述する名前を付ける • 実現手段については記述しない • 名前にはユビキタス言語を使う
  12. 12. 意図の明白なインターフェース 客 v: double r: int y: int b: int 塗料 paint(塗料)
  13. 13. 意図の明白なインターフェース 客 v: double r: int y: int b: int 塗料 paint(塗料) 客 volume: double red: int yellow: int blue: int 塗料 mixIn(塗料)
  14. 14. 意図の明白なインターフェース public void paint(Paint paint) { v = v + paint.getV(); // 混ぜ合わせた後に容量を合計する // 複雑な処理 }
  15. 15. 意図の明白なインターフェース public void testPaint() { Paint yellow = new Paint(100.0, 0, 50, 0); Paint blue = new Paint(100.0, 0, 0, 50); yellow.paint(blue); assertEquals(200.0, yellow.getV()); // 以下略 }
  16. 16. 意図の明白なインターフェース public void testPaint() { Paint ourPaint = new Paint(100.0, 0, 50, 0); Paint blue = new Paint(100.0, 0, 0, 50); ourPaint.mixIn(blue); assertEquals(200.0, ourPaint.getVolume()); // 以下略 }
  17. 17. 副作用のない関数 • 「副作用」のないものは「関数」と呼ばれる • 副作用のあるメソッドと関数を分離する • ある概念が値オブジェクトの責務に合致する場合 • そのメソッドを値オブジェクトで実装して副作用をなくす
  18. 18. 副作用のない関数 1.8 リットル 黄を表す色の値 塗料1 1.8 リットル 青を表す色の値 塗料2 3.6 リットル 緑を表す色の値 塗料1 ? リットル ? を表す色の値 塗料2 mixIn(塗料2)
  19. 19. 副作用のない関数 volume: double red: int yellow: int blue: int 塗料 mixIn(塗料) volume: double 塗料 mixIn(塗料) red: int yellow: int blue: int 顔料色 mixedWith(顔料色):顔料色
  20. 20. 副作用のない関数 public void mixIn(Paint other) { volume = volue + other.getVolume(); // 今の顔料色と他の顔料色を混ぜる pigmentColor = pigmentColor.mixedWith(other.pigmentColor()); }
  21. 21. (発展形)コマンドクエリ分離原則 インターフェースを次の2種類だけにする • コマンド • 副作用だけを行い値を返さない • クエリ • 副作用を持たず値だけを返す • https://en.wikipedia.org/wiki/Command%E2%80%93query_s eparation
  22. 22. コマンドクエリ責務分離アーキテクチャ • CQRS • サーバの責務をコマンドとクエリで完全に分ける • コマンド側アーキテクチャ • 複雑なロジックがあるのでドメイン層を活用 • 複雑なので遅い • クエリ側アーキテクチャ • 複雑なロジックはない。ドメイン層はスキップ • ドメイン層をスキップするので速い
  23. 23. 表明 • 操作の事後条件・不変条件を宣言する • プログラミング言語のサポート • 言語によっては事前条件・事後条件を記述できる • ユニットテスト • ドキュメント
  24. 24. 効果的な分解 高凝集かつ低結合を目指す • “概念の輪郭”を捉えて、ドメインとして意味のある単位に分割する • 設計要素を凝集した単位に分解する • 自分の直観も考慮に入れる • 「なぜこうして分割したか?」は説明できるようにしておく • なるべく“独立したクラス”を目指す • 他のクラスへの関連があると複雑になる • 一番望ましいのは他のクラスに一切の依存を持たないクラス • “閉じた操作”を目指す • 型のインスタンス集合の下で閉じている操作を定義する • 戻り値の型が引数の型と同じにできる場合はそのように定義する • 特に値オブジェクトは閉じた操作を目指したい
  25. 25. アナリシスパターン • 現実世界を対象にしたモデリングのパターン集 • 会計処理のパターンなど
  26. 26. デザインパターン DDD でのモデリングに役に立つパターン • コンポジットパターン • インタプリタパターン • フライウェイトパターン • ストラテジパターン
  27. 27. まとめ • 深いモデル・しなやかな設計のためのリファクタリング方法を 見てきた

×