トランザクションスクリプト方式とドメインモデル方式 違いの理解、発想の切り替え
ドメインモデル方式のクラス設計指針 カプセル化、契約プログラミング、自己文書化
できない理由/やらない理由 知識不足? 練度不足? 動機不足?
ドメインモデル方式のクラス設計に取り組む苦労話有限会社 システム設計 増田 亨【現場から学ぶモデル駆動設計 第17回】
View Slide
本日の座談会を企画した背景① 私への仕事の依頼のパターン• 既存システムの変更がやっかいで危険。なんとかしたい。• マイクロサービス 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&A2022/6/8 12
2022/6/8 13違いの理解・発想の切り替えドメインモデル方式(計算判断ロジック/ビジネスルール)トランザクションスクリプト方式(データ入出力手順)うまく伝えたいが伝わりにくいことカプセル化(ロジックとデータの一体化)契約プログラミング(メソッドの引数の型・返す型、イミュータブル)自己文書化(名前、パッケージ構成)できない理由/やらない理由知識不足? 練度不足? 動機不足?座談会のテーマ現場でどんな感じ?どうしようとしている?