$30 off During Our Annual Pro Sale. View Details »

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

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

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

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

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

増田 亨
PRO

June 07, 2022
Tweet

More Decks by 増田 亨

Other Decks in Programming

Transcript

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

  2. 本日の座談会を企画した背景 ① 私への仕事の依頼のパターン • 既存システムの変更がやっかいで危険。なんとかしたい。 • マイクロサービス and ドメイン駆動設計が良いのでは? •

    設計のアドバイスしてほしい ② あちこちでやってみると • 毎回同じような説明と助言をしている • ここを習得するとがらっと変わるという転換点もだいたい同じ • 同じような取り組みをしている高崎さん、谷口さん、藤岡さんと話をすると、 似たような経験をしている ③ 似たような経験をうまく言語化できたら現場で役に立ちそう 2022/6/8 2
  3. 話してみたいこと ① トランザクションスクリプト方式とドメインモデル方式 • アプローチの違いの伝え方 • 発想の切り替えの転機 ② うまく伝えたいけど伝わりにくいこと •

    カプセル化 • 契約プログラミング • 自己文書化 ③ できない理由/やらない理由 • 知識?、練度?、動機? 2022/6/8 3
  4. トランザクションスクリプト方式 ドメインモデル方式 違いの理解・発想の切り替え 2022/6/8 4

  5. 発想の切り替えが難しい? トランザクションスクリプト方式 • 機能クラス+データクラス • 機能クラスは、プレゼンテーション層からのリクエストを起点とする 一連のデータ処理の順次実行を記述 • データクラスは、画面単位(リクエスト単位) ドメインモデル方式

    • 計算判断ロジック(ビジネスルール)の置き場所 • クラス設計:カプセル化・契約プログラミング・自己文書化 • プレゼンテーション層とデータソース層からは完全に独立 2022/6/8 5
  6. トランザクションスクリプト方式の発想 データクラス • 凝集度:画面からのリクエストとして高凝集 • 結合度:画面やテーブルの項目群と密結合させる 他のデータクラスとは疎結合(重複あり) 機能クラス • 凝集度:画面からのリクエストの処理として高凝集

    :データベース操作手順の流れの途中に、計算式と条件分岐を 埋め込む :データ構造にコレクション/配列であればループ処理 • 結合度:他の機能クラスとは疎結合(重複あり) 2022/6/8 6
  7. ドメインモデル方式の発想 凝集度:関連するロジックとデータを一つのクラスに凝集する • 価格・数量・日付などの値の種類で凝集 • 区分定義(区分値・定数・計算判断ロジック)を凝集 • コレクション操作を凝集 • 計算判断の目的特化の集約クラスに凝集

    (凝集価格計算、値引きの判断、受注可否判断、…) 結合度:計算判断ロジック(ビジネスルール)の単位で分割 画面入出力の処理手順やタイミングから独立 データベース操作の処理手順やタイミングから独立 2022/6/8 7
  8. 伝えたいが伝わりにくいこと 2022/6/8 8

  9. うまく伝えたいが伝わりにくい? ① カプセル化 • ロジックをデータのある場所に配置する ② 契約プログラミング • 事前条件:引数の型で表明する •

    事後条件:メソッドの返す型で表明する • 不変条件:生成時の制約+イミュータブルに設計で保証する ③ 自己文書化 • 実行時にはどうでもいいが、人間には重要な情報 • 名前、パッケージ構造、… 2022/6/8 9
  10. できない理由/やらない理由 2022/6/8 10

  11. 何が不足しているのか? • 知識:そもそも知らない? • 練度:知っているが実践するには練度が足りない? • 動機:知っているし、やればできる。それでもやらない? 2022/6/8 11 前提として、

    ・ドメインモデル方式のクラス設計を良い設計だと思っている ・そういうクラス設計をやったほうが良いと思っている それでも、できない理由/やらない理由
  12. 座談会とQ&A 2022/6/8 12

  13. 2022/6/8 13 違いの理解・発想の切り替え ドメインモデル方式(計算判断ロジック/ビジネスルール) トランザクションスクリプト方式(データ入出力手順) うまく伝えたいが伝わりにくいこと カプセル化(ロジックとデータの一体化) 契約プログラミング(メソッドの引数の型・返す型、イミュータブル) 自己文書化(名前、パッケージ構成) できない理由/やらない理由

    知識不足? 練度不足? 動機不足? 座談会のテーマ 現場でどんな感じ? どうしようとしている?