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

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

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

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

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

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

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

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

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

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

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

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

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