radioc@?

レディオキャットハテナ

【勉強会メモ】Mix Leap Study #40 - Spring BootベースのDDDサンプル徹底解説!

yahoo-osaka.connpass.com

  • 日時:2019/04/04(木) 19:00 〜 21:30
  • 場所:ヤフー株式会社 大阪グランフロントオフィス

プラットフォームとプロセスを活かすための設計

遅刻したので聴けませんでした。

たかが命名、されど命名

山崎 好洋 さん

speakerdeck.com

思いやりのある命名をしよう

命名にどれだけ時間を使っているか?

  • クラス名
  • メソッド名
  • 変数名

命名にこだわらなくても動く

なぜ名前をつけるか?

  • 自分の書いたコードを理解するため
  • 他の人にも(未来の自分含む)
  • 全貌の把握に時間がかかる
  • 変更・削除の判断
  • 機能追加・変更に臆病

⇒サービスの成長鈍化

良い命名

  • 仕様のどの部分を表現しているのかがわかりやすい
  • 探しやすさ
  • 理解しやすい⇒こっちの話

理解しにくい命名は?

  • 仕様が理解できていない
  • 単語で命名しようとしている
  • クラスやメソッドがいろんなことをしようとしている

名前を考える

  • パターンを覚える(Dtoとか)
  • 文法をチームで決める(createとか)

付けちゃダメ

  • Manager
  • Util

Howを考えて分解する

判断する方法

  • 他の人にコードレビューしてもらう
  • 時間をおいてセルフレビュー

伝える方法

  • 命名
  • コメント
  • ドキュメント

コードとの距離

  • 命名のほうが近い
  • コードとの距離が遠いと情報の鮮度が落ちる

いつ、だれに、どれだけ伝えたいか?

思いやりをもった命名

Spring Bootベースのドメイン駆動設計のサンプルコード徹底解説

増田 亨さん

www.slideshare.net

github.com

  • Spring Boot
  • MVC
  • MyBatis
  • Thymeleaf

なぜ作ったか

  • 実アプリ並の具体例がほしかった
  • コードがいちばん具体的に伝えることができる
  • 質問が具体的になり、考え方の違いがはっきりする

何の具体例?

ソフトウェアの核心にある複雑さに立ち向かう

ドメイン駆動設計

  • 関心の分離の工夫
  • モジュール構造の工夫

複雑さに立ち向かう3つのキーワード

要点を絞り込む

何の具体例か?

  • ビジネスルールが複雑さの原因
  • 計算のモデリング
  • 型指向でプログラミングする

関心の分離の工夫

  • 計算(ビジネスルール)を実行するモジュール群
  • データを入出力するモジュール群

この2つを徹底的に分ける

同じモジュール(ソースファイル)に、計算と入出力を書かない

モジュール構造の工夫

手続き的な入出力モジュールに計算を埋め込む(トランザクションスクリプト

計算を型(値の種類)でモジュール化して組み合わせる(ドメインモデル)

サンプルアプリケーションの概要

  • 時給ベースの給与計算アプリケーション
  • 背景にあるビジネスルール
  • 計算に必要な事実
    • 勤務実績(いつ、何時間)
  • 給与計算ルールを62種類の型で記述
  • 本日は、給与(Payroll)型を中心に説明

給与型を中心にレイヤごとに説明

  • ドメイン
  • アプリケーションそう
  • データソース層とデータベース
  • プレゼンテーション層

ビジネスルールを記述する3要素

  • Fact
    • 事実の表現
  • Rule
    • Factを使った計算や判定ロジック
  • Goal
    • 知りたいこと

ドメイン層の設計の考え方

計算モデルが息づく場所

  • mdoelパッケージ
  • typeパッケージ

⇒modelに置くか、typeに置くかは書いてみながら判断・調整

型指向のプログラミング

Plain Old Java

  • Bean Valid
  • 可読性 over Javaの習慣的な気泡
  • No getter, no setter, no Lombok, no JPA

60種類の独自の型を9つのパッケージに整理 特定のパッケージに矢印が集まっていないかなどをチェック

f:id:radiocat:20190405185725p:plain

  • 区分ごとのロジックの整理
  • 区分に依存するロジックの視覚化

アプリケーション層

ビジネスの記述を独立させる

  • ビジネスルールの記述をビジネスロジック層に移動
  • 理論的にはアプリケーション層はとてもシンプルになる
  • 現実にはアプリケーション層に複雑な記述が残りやすい

アプリケーション層の要素分解

  • 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(のざきひろふみ)さん

github.com

三層+ドメインモデルのアーキテクチャで実装されたコードから分析・設計情報を出力するツール

  • ドキュメントは一時的に見るもの

コードによる設計のためのツール

依存関係の逆転

  • ドキュメントからコードではなく、コードからドキュメントに
  • 意図を込めてコードを書いて意図が表現されたドキュメントを見る

コード→ドキュメント→設計

※設計へのフィードバック

  • コードがドキュメントに見えればコードで設計できる
  • 良いコードはドキュメント化が容易

前提条件を加える

三層+ドメインモデル

not UML

  • 汎用的なクラス図などは既存ツールにまかせて良い
  • ビジネスルールが際立つものを
    • 意図を込めたところを読み取る
  • 想定外の作りはいびつに見えればよい

実現方法

  • コードを読むとき、いつも同じ

    • ところを見ている
    • たどり方をしている
    • 絵を描いている
  • コードの理解をモデリングできれば

    • 複数の分析設計ドキュメントを作成できる
    • 設計へのフィードっバックを早められる

使い方

※参考

speakerdeck.com