Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

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

増田 亨

June 07, 2022
Tweet

More Decks by 増田 亨

Other Decks in Programming

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide