【勉強会メモ】Mix Leap Study #40 - Spring BootベースのDDDサンプル徹底解説!
- 日時:2019/04/04(木) 19:00 〜 21:30
- 場所:ヤフー株式会社 大阪グランフロントオフィス
プラットフォームとプロセスを活かすための設計
遅刻したので聴けませんでした。
たかが命名、されど命名
山崎 好洋 さん
思いやりのある命名をしよう
命名にどれだけ時間を使っているか?
- クラス名
- メソッド名
- 変数名
命名にこだわらなくても動く
なぜ名前をつけるか?
- 自分の書いたコードを理解するため
- 他の人にも(未来の自分含む)
- 全貌の把握に時間がかかる
- 変更・削除の判断
- 機能追加・変更に臆病
⇒サービスの成長鈍化
良い命名
- 仕様のどの部分を表現しているのかがわかりやすい
- 探しやすさ
- 理解しやすい⇒こっちの話
理解しにくい命名は?
- 仕様が理解できていない
- 単語で命名しようとしている
- クラスやメソッドがいろんなことをしようとしている
名前を考える
- パターンを覚える(Dtoとか)
- 文法をチームで決める(createとか)
付けちゃダメ
- Manager
- Util
Howを考えて分解する
判断する方法
- 他の人にコードレビューしてもらう
- 時間をおいてセルフレビュー
伝える方法
- 命名
- コメント
- ドキュメント
コードとの距離
- 命名のほうが近い
- コードとの距離が遠いと情報の鮮度が落ちる
いつ、だれに、どれだけ伝えたいか?
思いやりをもった命名を
Spring Bootベースのドメイン駆動設計のサンプルコード徹底解説
増田 亨さん
- Spring Boot
- MVC
- MyBatis
- Thymeleaf
なぜ作ったか
- 実アプリ並の具体例がほしかった
- コードがいちばん具体的に伝えることができる
- 質問が具体的になり、考え方の違いがはっきりする
何の具体例?
ソフトウェアの核心にある複雑さに立ち向かう
ドメイン駆動設計
- 関心の分離の工夫
- モジュール構造の工夫
複雑さに立ち向かう3つのキーワード
要点を絞り込む
何の具体例か?
- ビジネスルールが複雑さの原因
- 計算のモデリング
- 型指向でプログラミングする
関心の分離の工夫
- 計算(ビジネスルール)を実行するモジュール群
- データを入出力するモジュール群
この2つを徹底的に分ける
同じモジュール(ソースファイル)に、計算と入出力を書かない
モジュール構造の工夫
手続き的な入出力モジュールに計算を埋め込む(トランザクションスクリプト)
↓
計算を型(値の種類)でモジュール化して組み合わせる(ドメインモデル)
サンプルアプリケーションの概要
- 時給ベースの給与計算アプリケーション
- 背景にあるビジネスルール
- 計算に必要な事実
- 勤務実績(いつ、何時間)
- 給与計算ルールを62種類の型で記述
- 本日は、給与(Payroll)型を中心に説明
給与型を中心にレイヤごとに説明
- ドメイン層
- アプリケーションそう
- データソース層とデータベース
- プレゼンテーション層
ビジネスルールを記述する3要素
- Fact
- 事実の表現
- Rule
- Factを使った計算や判定ロジック
- Goal
- 知りたいこと
ドメイン層の設計の考え方
計算モデルが息づく場所
- mdoelパッケージ
- typeパッケージ
⇒modelに置くか、typeに置くかは書いてみながら判断・調整
型指向のプログラミング
- wiki:設計ガイドライン · masuda220/business-logic-patterns Wiki · GitHub
- スライド:ドメイン駆動設計 本格入門
- 書籍:現場で役立つシステム設計の原則
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
- 作者: 増田亨
- 出版社/メーカー: 技術評論社
- 発売日: 2017/07/05
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
Plain Old Java
60種類の独自の型を9つのパッケージに整理 特定のパッケージに矢印が集まっていないかなどをチェック
- 区分ごとのロジックの整理
- 区分に依存するロジックの視覚化
アプリケーション層
ビジネスの記述を独立させる
- ビジネスルールの記述をビジネスロジック層に移動
- 理論的にはアプリケーション層はとてもシンプルになる
- 現実にはアプリケーション層に複雑な記述が残りやすい
アプリケーション層の要素分解
- Factoryサービス
- 計算モデルのインスタンスを生成⇒データソース層で事実を元に生成
- Queryサービス
- 計算結果を返す⇒プレゼンテーション層へ
- Operationサービス
- 計算結果を記録/通知⇒データソース層へ
※ 3つに分けるかどうかは設計の考えどころ
データベース層とデータベース
- 計算モデルとデータモデルのマッピング
データソース層設計の考え方とやり方
- データの入出力の実装
- MyBatis SQL Mapper
- SELECTの実行→計算用のオブジェクトの生成
- 記録すべき事実をもったオブジェクト→INSERTの実行
- ContractDataSource
- Thymeleaf
データベース設計の考え方とやり方
- プログラムからは独立したデータの記録と参照の仕組み
- イミュータブルなデータモデル:事実の履歴+最新状態
- 事実の履歴→INSERTオンリー
- 最新状態の導出結果→DELETE/INSERT
- NO UPDATE
- NO update_atカラム
- 制約指向
- データ型
- NOT NULL制約、外部キー制約、ユニーク制約
- とことん日本語
プレゼンテーション層
- 計算モデルのビュー
- ドメインオブジェクトをそのまま表示(naked objectパターン指向)
- Spring MVC
- Direct Field Access → WebDataBinder#initDirectFieldAccess()
- Thymeleaf
- Semantic UI
- PayrollControllerクラス
- temples/payroll/list.html
※参考
www.slideshare.net
JIG
irof(のざきひろふみ)さん
三層+ドメインモデルのアーキテクチャで実装されたコードから分析・設計情報を出力するツール
- ドキュメントは一時的に見るもの
コードによる設計のためのツール
依存関係の逆転
- ドキュメントからコードではなく、コードからドキュメントに
- 意図を込めてコードを書いて意図が表現されたドキュメントを見る
コード→ドキュメント→設計
※設計へのフィードバック
- コードがドキュメントに見えればコードで設計できる
- 良いコードはドキュメント化が容易
前提条件を加える
三層+ドメインモデル
not UML
- 汎用的なクラス図などは既存ツールにまかせて良い
- ビジネスルールが際立つものを
- 意図を込めたところを読み取る
- 想定外の作りはいびつに見えればよい
実現方法
コードを読むとき、いつも同じ
- ところを見ている
- たどり方をしている
- 絵を描いている
コードの理解をモデリングできれば
- 複数の分析設計ドキュメントを作成できる
- 設計へのフィードっバックを早められる
使い方
※参考