mike-neckのブログ

Java or Groovy or Swift or Golang

JSUG勉強会 2017 - 3 〜ドメイン駆動設計 powered by Spring のメモ

java 勉強会

JSUGの勉強会に参加したので、そのメモ。

jsug.doorkeeper.jp

資料は公開されるだろうから、ここでしか聞けないことを中心にメモ(ツイート)したつもりだが、資料に盛り込まれている可能性は十分にある。なお、資料は以下の通り。

www.slideshare.net

個人的な感想

  • ドメイン駆動のセッションや話は「ドメイン駆動はいいぞ」という感じで抽象的な話になりがちなことが多いのだが、今回はフレームワークが限定されたこともあってどのようなオブジェクトをどのように作っていくという具体的な話が聞けて満足だった
  • ビジネスルールとドメインロジック
    • ビジネスルール(契約・法令・明文化されていない商習慣)などがソフトウェア開発の分析対象(もちろん、ビジネスルールがゲームのルールだったりサービスのルールだったりもする)
    • その分析結果をプログラミング言語で表現したものがドメインロジック

  • ソフトウェア開発のプロセス
    • いわゆるウォーターフォールのプロセス(情報収集・分析・設計・実装・テスト・リリース・運用)に加えてモデリングをおこなう
    • モデリングすると無理・無駄・ムラが減る
    • しかしモデリングするから仕様を決めなくてよいというわけではない
    • これらのプロセスをすべて毎日やる
  • Spring Frameworkとドメイン駆動

  • いわゆるウォーターフォール(個人の所感を含む)

    • 一般的な文脈で言うSIerのウォーターフォールは「伝言ゲーム」
    • 「伝言ゲーム」 = 顧客へのヒアリングする人と設計する人と開発する人が違うような開発
      • まあ、規模が大きいからと言って数百人とか用意しているようなプロジェクトだと、数百人で顧客のところへ押しかけても顧客が迷惑するだけですけどね…
    • もちろんフレームワークを何を選定するかはプロジェクトの自由なので、Spring Bootで「伝言ゲーム」開発も可能

  • ソフトウェアの構成

トランザクションスクリプト = ドメインモデルを構築しない手続きだけを書いたソフトウェア

トランザクションスクリプト型のSpringアプリケーションの構成

f:id:mike_neck:20170329221918p:plain

ドメイン駆動設計によるSpringアプリケーションの構成

f:id:mike_neck:20170329222009p:plain

ドメイン駆動でアプリケーションを作ると、各層とは別にドメインモデルの層を用意して、ここをインクリメンタルに成長させていく

  • ドメインモデル
    • ビジネスロジックの要素は次のものしかない
      • 数値
      • 日付
      • 文字列
    • オブジェクトの種類は次の3パターン
      • 値オブジェクト(数値/日付/文字列をラップしただけのオブジェクト、いわゆるValue Object)
      • 区分オブジェクト(振る舞いをもった enum)
      • コレクションオブジェクト(List や Set をラップしたオブジェクト(List や Set には直接触れさせないで、必要な操作だけを提供する))
  • モジュールの単位
  • ドメインオブジェクトとその他の層

  • ソースコードの文書化

    • メソッド名、クラス名だけでなく、メソッドの返す型、引数の型にはJava APIが出てこないようにして、ソースコードが自然とドメインを語るようにする

  • 具体的なドメインモデルによるSpringアプリケーションの構成

    • HTML ⇔ Controller ⇔ ドメインオブジェクト(プレゼンテーション層)
      • コントローラーはドメインオブジェクトを引数に取るようにする
      • 表示処理(〜の場合には表示する/しない)の演算をプレゼンテーション層には書かない(すべてドメインモデルにておこなう)
      • ドメインオブジェクトにはgetter/setterを設けず、 DirectFieldAccess を有効化してフィールドアクセスする
    • サービス層(アプリケーション層)
      • サービス層(アプリケーション層)には @Validated を引数のドメインオブジェクトにつけておいて、契約による設計を実現させる
    • データソース層
      • データベース層とドメインオブジェクトは別物ゆえ、マッピングを作っている(MyBatis使用)
      • ドメインオブジェクトはロジックの置き場なので、テーブルの論理を持ち込まない
      • データベース層も更新が楽になる、かつデータベースの論理を徹底できるように、きっちり正規化する

後半のトークセッション

ドメインモデルの用語はどこから取り入れているのかという質問に対して

同じく名前についてわたびきさんのエピソード

ロジックの順序について

既存コードが有る状態でのドメイン駆動の取り込み方 : 少しずつ入れていく