はじめに
こんにちは!さいけです。
先日、六本木で行われたDDDの勉強会に参加してきました。
以下、イベント詳細になります。
また、本記事はその時のメモ的な記事になります。(メモが雑ですが、ご容赦ください…)
勉強会メモ
はじめに
以下3つがドメイン駆動設計の核心
- 複雑さはビジネスルールに依存する
- 計算をモデリング
- 型思考でプログラミング
今日はサンプルコードを見せながらドメイン駆動設計を解説していく
以下、本日使うスライドとリポジトリ
■DDD sample code explained in Java
■GitHub – system-sekkei/isolating-the-domain: architecture sample using : Spring Boot gradle, Spring MVC, Thymeleaf, and MyBatis
告知:3/22 のDevLove Premium「ドメイン駆動設計 本格入門」でもっと詳しいことを解説します
ドメイン駆動設計は関心の分離
データの入出力とデータの計算を分ける
ドメイン層
型思考プログラミング
設計ガイドラインをサンプルとして紹介している
■設計ガイドライン · masuda220/business-logic-patterns Wiki · GitHub
Plain Old Java
- bean validation → 有効値の証明・自己文章化
- 可読性 習慣的な記法
- no getter, no setter, no Lombok, no JPA
Q&A
Q.streamAPIを使わないのはなぜ?
A.個人的にあまり好きじゃない。おもて面のところではforを使う。streamを使うなら深いところで隠蔽するべき
Q.バリデーションはどこでするべき?
A.色々な層でやったほうがいい
Q.型に関連する計算はどこでやる?
A.型関連の計算はその型内でやったほうがいい
Q.Getterを使わないのはなぜ?
A.自己文章化しているから
Q.コントローラとドメインでのバリデーションの違いはあり?
A.複雑になる原因
アプリケーション層
プレゼンテーション層に値を返したり、データソース層から値を引っ張ってきたりする
主にServiceクラスが入る
データソース層
Mybatis推しの増田さん
データベース
イミュータブルデータモデルを強く意識してやっている
イミュータブルデータモデルのオススメ資料は以下
■イミュータブルデータモデル(入門編)
データを記録する際はINSERTのみ
UPDATE文は使わない
情報の更新をするときはDELETE+INSERT
Q&A
Q.イミュータブルはデータサイズがどんどん増えていくのでは?
A.増田さんが作っているアプリケーションは小さいレベルだから適応できる。あと今の時代なら多少大丈夫ではないか。
Q.カラム名はなんで日本語?
A.日本語の方がわかりやすいから
Q.日本語だとやりづらくない?
A.そんなことはない。わかりやすい。一応だが、実験的にやっている
プレゼンテーション層
ViewファイルやControllerクラスが置かれるところ
thymeleafとかSemanticUI使ってる
JIG
自作ツール
あるクラスがどのクラスに依存しているか、ロジック複雑なクラスはないか等を可視化できるツール
簡単にプロジェクトに追加できる
■GitHub – dddjava/Jig: Java Instant-document Gazer
おわりに
今回、DDDの勉強会に参加して、個人的に学びが多かったと思います!
増田さんの書籍は結構前から読んでいて参考にはしていたのですが、直接DDD勉強会に参加して実際に話を聞いてみると書籍とは違った学びが得られて、とても良かったです。
今後の開発において、増田さんのDDDの考え方で良いとこはちゃんと取り入れて開発していきたいなと思いました。
それじゃ!( ・∇・)
コメント