ドメイン駆動設計 powered by Springを聞いてきた！

３月２８日、

JSUG勉強会 2017年その3 ～ ドメイン駆動設計 powered by Spring

を聞いてきた！ので、内容をメモメモ

---

■ドメインロジックに集中せよ
・ドメイン駆動設計
　ソフトウェアの核心にある複雑さに立ち向かう

・設計を複雑にする要因
　　技術的な複雑さ
　　ドメインの複雑さ

・核心の複雑さに立ち向かう
　ドメインロジックに集中する
　モデルに基づき設計する
　インクリメンタルに開発する

・ドメインロジックに集中する
　ビジネスルール　：分析の対象→遵守すべき約束事
　ドメインロジック：実装の対象→ビジネスルールのサブセット
　　　　　　　　　　　　　　　　プログラミング言語で記述

・モデルに基づき設計する
　モデルとオブジェクト
　モデルのない開発プロセス
　　情報収集
　　分析整理
　　仕様　　モデル（アドオンの作業）
　　設計
　　実装
　→ドメインモデルを一切持っていない

　モデリングという作業を入れる
　→全体の見通しがよくなる

・インクリメンタルに開発する
　フェーズに分ける開発
　　担当者が変わる：伝言ゲーム
　　一方向　つじつまあわせ
　インクリメンタルな開発
　　すべては発展途上になる
　　同じチームで対応する

・素敵なお知らせ
　複雑さに立ち向かう強力な援軍
　Spring Framework Spring Boot
　Spring Framework
　　ドメインモデル以外のことを全部用意するフレームワーク

　Spring Boot
　　いったんは動かせ。Github作って。

・残念なお知らせ
　こんな開発もできる
　　技術課題に集中する
　　バックログをせっせと消化する
　　フェーズに分けて伝言ゲーム・基盤とアプリの分離

・アンチパターン
　データ処理に焦点をあてる
　　プレゼンテーション層：画面の入出力 @Controller
　　アプリケーション層　：データベースの更新・参照の手続き @Service
　　データソース層：データベースの入出力 @Repository
　　　　｜
　　　　↓　ドメインロジックを
　　ドメインモデル
　　　　　ここに集約する

・ドメインモデル
　マーチンファウラー
　　オブジェクトモデル
　　振る舞いとデータ

・ドメインモデル
　ドメインロジックをオブジェクトで表現する

・ドメインモデルだと何がよいのか
　変更が楽で安全になる

・ドメインモデル：変更容易性
　　ドメインロジックが重複しない
　　どこにロジックが書いてあるか特定しやすい
　　変更の影響を狭い範囲に限定できる

・トランザクションスクリプト
　同じロジックが重複する
　データ処理の流れを追いかけて探し回る
　後続の処理をすべて追いかける

・ドメインオブジェクト設計パターン
　　ビジネスルール
　　ドメインロジック

・ドメインロジックの最小単位
　　演算の対象
　　　数値
　　　日付
　　　文字列
　　演算
　　　等値の判定
　　　大小・順序
　　　範囲内
　　　有効
　　　型変換
　　　四則演算・変換
　　　
・最小単位→３つの型にまとめられる
　値オブジェクト
　　　汎用の型　→　独自に定義した型
　コレクションオブジェクト→リスト、セット
　区分オブジェクト　→　振る舞いを持ったenum
　　　　　　　　　　　　Strategy,Stateパターン

・設計原則
　　モジュール化：複雑さに立ち向かうための工夫
　　　　ドメインモデル：オブジェクトモデル／関心ごと
　　　　トランザクションスクリプト：機能
　　構造化：記述レベルを階層化する
　　　　業務で使う用語
　　　　ドメイン固有API→このレイヤをしっかり書く
　　　　JavaコアAPI
　　　　Java言語仕様
　　※動かすだけならドメイン固有APIはオーバーヘッドだが、
　　　ドメイン駆動設計には必要
　　文書化
　　　ソースコードに自己文書化
　　　　パッケージ名／クラス名／メソッド名

・ドメインロジックの文書化
　ドメインオブジェクトを使うほかの三層のコード
　　　ドメインロジックとの関係性を語るようになる
　　　　（自己文書化が波及する）
　ソースコード以外の文書化
　　　業務マニュアル
　　　利用者ガイド
　　　（不要）開発・保守ドキュメント

・ドメインを隔離する
　　基盤側にドメインロジックを持っていかないこと
　　　→つまり、アノテーションのかかったメソッドに
　　データの入出力とドメインモデル

　　画面やデータベースの都合をドメインに持ち込まない

・プレゼンテーション層とドメインオブジェクト
　　ドメインオブジェクトを直接使う
　　プレゼンテーション層の記述をドメインモデルに依存させる
　　プレゼンテーション層に判断・加工・計算のロジックを置かない
　　　HTTPリクエスト→ドメインオブジェクト：DirectFieldAccess
　　　ドメインオブジェクト→HTTPレスポンス：HTMLテンプレート

・PRG

・DirectFieldAccess
@ControllerAdvice
　@initBinder
あとは#kanjava MVCで検索

・アプリケーション層とドメインオブジェクト
　@Service
　@Validated　：引数にかけてしまう
　リポジトリを@Autowiredする

　ドメインの関心事としての永続化
　　インターフェース宣言
　　データベースの都合をドメインオブジェクトに持ち込まない

・データソース層とドメインオブジェクト
　@Repository
　MyBatisSQLmapping
　　オブジェクトとテーブルは別の世界
　　手作業で明示的にマッピングしている
　resultMapに明示的に書く

・まとめ

■トークセッション
・変える気があるか
・リードする人がいないと・・
・ぐれいるずをつかおう
・数百人にDDDの厚い本を実践する？
・経験者を作る
・リファクタリングの形で書き換える
・本開発が始まる前に作るしかない
　　→縛りをかけてしまうと、
・ウォーターフォールでDDD
　　いけるんじゃないか？
・データさんがかじを切るだけでも変わる
　→てらそるなに「リッチなドメインモデルは書かない」とかの記述に
　　たいして、こういうときならというのをちょこっと書いてくれるだけでも、
　　世の中は変わる。
・自分の知らないドメインは
　　→パクってくる。Day1はできてない。でも１週目にはできていないと・・
　　　用語集とかは渡していない
・業務で使う日本語：横幅いっぱいになる：日本語でクラス作る？
　　enumは日本語で書いている。日本語でやると違和感
　　大規模はローマ字、子音だけはあるけど、
・ドメインモデルを作るコツ
　　値オブジェクト：ドメイン駆動はオーバーヘッド　結果的によくなる
・実装　MyBatisでなくてもJPAでもできるけど、
・オブジェクトの組み合わせでロジックを作る
　順序依存性があるものは、サービスに書いている