ドメインモデル方式のクラス設計 座談会

トランザクションスクリプト方式とドメインモデル方式
違いの理解、発想の切り替え

ドメインモデル方式のクラス設計指針
カプセル化、契約プログラミング、自己文書化

できない理由／やらない理由
知識不足？　練度不足？　動機不足？

Transcript

1. ドメインモデル方式の
   クラス設計に取り組む苦労話
   有限会社 システム設計 増田 亨
   【現場から学ぶモデル駆動設計 第17回】
   

   View Slide

2. 本日の座談会を企画した背景
   ① 私への仕事の依頼のパターン
   • 既存システムの変更がやっかいで危険。なんとかしたい。
   • マイクロサービス and ドメイン駆動設計が良いのでは？
   • 設計のアドバイスしてほしい
   ② あちこちでやってみると
   • 毎回同じような説明と助言をしている
   • ここを習得するとがらっと変わるという転換点もだいたい同じ
   • 同じような取り組みをしている高崎さん、谷口さん、藤岡さんと話をすると、
   似たような経験をしている
   ③ 似たような経験をうまく言語化できたら現場で役に立ちそう
   2022/6/8 2
   

   View Slide

3. 話してみたいこと
   ① トランザクションスクリプト方式とドメインモデル方式
   • アプローチの違いの伝え方
   • 発想の切り替えの転機
   ② うまく伝えたいけど伝わりにくいこと
   • カプセル化
   • 契約プログラミング
   • 自己文書化
   ③ できない理由／やらない理由
   • 知識？、練度？、動機？
   2022/6/8 3
   

   View Slide

4. トランザクションスクリプト方式
   ドメインモデル方式
   違いの理解・発想の切り替え
   2022/6/8 4
   

   View Slide

5. 発想の切り替えが難しい？
   トランザクションスクリプト方式
   • 機能クラス＋データクラス
   • 機能クラスは、プレゼンテーション層からのリクエストを起点とする
   一連のデータ処理の順次実行を記述
   • データクラスは、画面単位（リクエスト単位）
   ドメインモデル方式
   • 計算判断ロジック（ビジネスルール）の置き場所
   • クラス設計：カプセル化・契約プログラミング・自己文書化
   • プレゼンテーション層とデータソース層からは完全に独立
   2022/6/8 5
   

   View Slide

6. トランザクションスクリプト方式の発想
   データクラス
   • 凝集度：画面からのリクエストとして高凝集
   • 結合度：画面やテーブルの項目群と密結合させる
   他のデータクラスとは疎結合（重複あり）
   機能クラス
   • 凝集度：画面からのリクエストの処理として高凝集
   ：データベース操作手順の流れの途中に、計算式と条件分岐を
   埋め込む
   ：データ構造にコレクション/配列であればループ処理
   • 結合度：他の機能クラスとは疎結合（重複あり）
   2022/6/8 6
   

   View Slide

7. ドメインモデル方式の発想
   凝集度：関連するロジックとデータを一つのクラスに凝集する
   • 価格・数量・日付などの値の種類で凝集
   • 区分定義（区分値・定数・計算判断ロジック）を凝集
   • コレクション操作を凝集
   • 計算判断の目的特化の集約クラスに凝集
   （凝集価格計算、値引きの判断、受注可否判断、…）
   結合度：計算判断ロジック（ビジネスルール）の単位で分割
   画面入出力の処理手順やタイミングから独立
   データベース操作の処理手順やタイミングから独立
   2022/6/8 7
   

   View Slide

8. 伝えたいが伝わりにくいこと
   2022/6/8 8
   

   View Slide

9. うまく伝えたいが伝わりにくい？
   ① カプセル化
   • ロジックをデータのある場所に配置する
   ② 契約プログラミング
   • 事前条件：引数の型で表明する
   • 事後条件：メソッドの返す型で表明する
   • 不変条件：生成時の制約＋イミュータブルに設計で保証する
   ③ 自己文書化
   • 実行時にはどうでもいいが、人間には重要な情報
   • 名前、パッケージ構造、…
   2022/6/8 9
   

   View Slide

10. できない理由／やらない理由
    2022/6/8 10
    

    View Slide

11. 何が不足しているのか？
    • 知識：そもそも知らない？
    • 練度：知っているが実践するには練度が足りない？
    • 動機：知っているし、やればできる。それでもやらない？
    2022/6/8 11
    前提として、
    ・ドメインモデル方式のクラス設計を良い設計だと思っている
    ・そういうクラス設計をやったほうが良いと思っている
    それでも、できない理由/やらない理由
    

    View Slide

12. 座談会とQ&A
    2022/6/8 12
    

    View Slide

13. 2022/6/8 13
    違いの理解・発想の切り替え
    ドメインモデル方式（計算判断ロジック/ビジネスルール）
    トランザクションスクリプト方式（データ入出力手順）
    うまく伝えたいが伝わりにくいこと
    カプセル化（ロジックとデータの一体化）
    契約プログラミング（メソッドの引数の型・返す型、イミュータブル）
    自己文書化（名前、パッケージ構成）
    できない理由／やらない理由
    知識不足？ 練度不足？ 動機不足？
    座談会のテーマ
    現場でどんな感じ？
    どうしようとしている？
    

    View Slide