mono(0w0)ログ

読んで、体験して、自分でやってみた記録

Mix Leap Study #40 - Spring BootベースのDDDサンプル徹底解説! に参加した

以下、当日とったメモ。整理しきれていないけどこのままだといつまでも書けないと思ったのでそのまま。自分用に残す。

Mix Leap Studyについて

  • 情報共有を定期的に行う場
  • Yahoo社員・社会人・学生の交流

プラットフォームとサービスを支える設計

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

  • エヴァンス本:諦める
  • 実践ドメイン駆動設計:
  • 命名にどれだけ時間使いますか?
    • 自分の書いたコードを理解できるようにするため
    • 他の人(未来の自分も)がコードを理解できるようにするため
  • 良い命名:仕様のどの部分を表現しているかわかりやすい
  • 下地
    • よく使われる命名を覚える
    • ルールを決める
  • アンチパターンの場合は、Howを考えて直す
  • コードとの距離が遠くなれば情報の鮮度が落ちる
    • 伝える方法は目的に応じて選択する

DDDサンプルのお話

  • 作った理由:コードが一番具体的、質問も具体的になる
  • 核心にある複雑さに立ち向かう
  • 設計の大原則:関心の分離・モジュール構造の工夫
  • 3つのキーワード
  • 要点を絞り込む
    • ビジネスルール:データモデルで頑張ろうは書いてない(エヴァンス本)
    • 計算モデル:
    • 型指向のプログラミング:
  • 関心の分離の工夫
    • 計算(ビジネスルール)を実行するモジュール群
    • データを入出力するモジュール群
    • この2つを徹底的に分ける
  • モジュール構造の工夫
  • サンプルは給与計算アプリケーション
    • 給与:Payroll
  • ドメイン
    • ビジネスルールの3要素
      • Fact:事実の表現
      • Rule:計算式、判定式
      • Goal:計算結果や判定結果を表現する型
    • 設計とやり方
      • modelパッケージ:計算モデル
      • typeパッケージ:モデルを表現するための基本部品のライブラリ
      • 型指向のプログラミング
        • GithabのWikiに記載してます
        • ドメイン駆動設計本格入門
        • 増田さんの本
      • Plain Old Java
        • ビーンバリデーションのアノテーションは積極的に使う
        • privateは省略する(意見が分かれるところ)
        • ライブラリも意見が割れる箇所
    • Jig
      • 作り始めた時はどのパッケージから作り始めたのかな?
        • 事実が先かな。行ったり来たり★
      • パッケージ間の依存関係を見て不自然さのところを是正していく
      • enumを可視化している
      • コレクションオブジェクトからlistを取り出して実装しているのはなぜか?
        • contractとアテンダンスを依存させたくなかった★
  • アプリケーション層
    • ビジネスルールの記述を独立させる
    • 理論的にはアプリケーション層はシンプルになる
    • 現実は複雑な記述が残りやすい
    • 要素分解
      • Factoryサービス:計算モデルのインスタンスを生成する:データソース層で事実を元に生成
      • Queryサービス:計算結果を返す:プレゼンテーション層へ
      • Operationサービス:計算結果を記録/通知する:データソース層へ
    • 複合サービス(要素サービスをDI)→要素サービス(repositoryをDI)
      • 複合はcoordinator:repositoryは見ない
    • QA
      • repository:周辺
      • 色々なサービスを組み合わせないと実現できないので複合にしている。要素で満たせるのであればおk
      • ゴールが次のファクトになることもある
      • 本当はcoordinatorとかQueryとかつけたくないので
      • コンストラクタが1つであればアノテーションを書かなくてもSpringが勝手にDIしてくれる
        • コンストラクタインジェクション以外を使わないでね@irofさん
        • autowired使うとユニットテストができない
      • データソースで組み立てるパターン、サービス層で組み立てるパターン色々ある
        • ダッシュボードを組み立てるのであればプレゼンテーション層でやる方がいい時も
  • データソース層とデータベース
    • 計算モデルとデータモデルのマッピング
    • 事実としてどのように記録する ことと 事実をどのようにして計算する かはそんなにインピーダンスミスマッチ無いよ
    • SELECTの実行=計算用のオブジェクト生成
    • 記録すべき事実を持ったオブジェクト=INSERTの実行
    • RDBの設計は特定のアプリケーションから独立させる
    • イミュータブルデータモデル:事実の履歴+最新状態
    • UPDATEは使わない
    • 川島さんのスライド
    • 制約指向:NOT NULL制約、外部キー制約
    • DBに日本語命名が良い
      • Mybatisの実装でas句を記載するとresultMapタグがなくなる★
    • QA
      • coordinatorがまとめて取得してという性能
      • データベースの箇所には大量データとの戦いがある
      • 業務に本当に必要なのか考える
  • プレゼンテーション層
    • 計算モデルのビュー
    • Spring MVC
      • Direct Field Access:WebDataBinder#initDirectFieldAccess()
        • Mybatisがgetter/setterを要求することはない(Springだけかな?)
    • Thymleaf
      • ドメインオブジェクトをプレゼンテーション層から使う
      • ドメインオブジェくとの変更がプレゼンテーション層に影響を与えるのは計算モデルのビューという考えからいうと良い依存と考える
    • QA
      • ロバストネス的な考えて行ったらコントローラーでユースケースを実現している
      • アクターが異なるのであればアプリケーションごと変えることもやった
      • APIコンポーザー:クライアントからのリッチな要求に対応する。ドメインを変換する層

JIG(治具)

  • ドキュメントは一時的に見るだけ
  • コードの設計によるためのツール
    • 意図を込めてコードを書いて、意図が表現されたドキュメントを見る
    • 設計・コード・ドキュメントのサイクルを回す
      • ドキュメント生成ツールではない。設計補助ツール
    • Not UML
      • ビジネスルールが際立つもの
      • 意図を込めたところを読み取る
    • 想定外の作りは歪に見えればいい
      • 見えるだけ
      • 頭の中と実装の乖離を可視化する
    • コードの理解をモデリングできれば
      • 分析設計ドキュメント