現場で役立つシステム設計の原則でお馴染み、増田さんのDDDの話ちゃんと聞いたことなかったのでドメイン駆動設計 本格入門に行ってきたよメモ
公演の内容
ドメイン駆動設計本格入門
今日の夜の #devlove Premium のイベントで発表する資料です。
— 増田 亨. (@masuda220) 2019年3月22日
内容が細かいページがあるので、事前に公開しておきます。https://t.co/spqEO8CUED
感想
3つの観点への変換
ドメインロジックをビジネスルール、ドメインモデルを計算モデルとして置き換えるという考えはなるほどなーという感じで思えた。またオブジェクト指向も根幹の部分である型に注目することで、一番コアな部分を説明しているという風に感じた。
ビジネスルールの分解も値オブジェクト、enum、コレクションのカプセル化と表現していて値オブジェクトとカタログ的な部分は書籍の記憶もありすんなり理解できたがenumで分解していく部分に関しては感覚ではわかるが人に説明するときにちゃんと説明できなそうな部分なのでエヴァンス本などで補強したく思った。
契約による設計をassetではなく値オブジェクトによる型での宣言という考えはなるほどなと思わせる部分が多く、基本的にnullを許容しないkotlinやswiftとあわせて考えるとかなり有用な考え方になると感じた。
手続き型(トランザクション)の部分をなるべく値オブジェクトに寄せる、手続きになるようなものはオブジェクトにするという部分に関してもいまいちピンと来ておらず
- 引数に値オブジェクトの連鎖が続くと相互依存の強いものになってしまうのではないか
- 手続きになる部分はアプリケーションレイヤに書くのか?
という疑問は残ったので、ここらへんは自身で書いて行くしか無いのかなという部分だった
エヴァンス本の解釈、読み解き方
エヴァンス本に関して語られるなかで印象的に残ったのが
という2点で、セットで語られることが多いIDDD本に関して解釈が違うという見解は初めて聞いた部分もあり、原典にちかいエヴァンス本の見え方や見解が人によって異なる部分は改めて垣間見た気がした。
また3部と4部に関しては改めて読む切り口を提示されたので読み直してみようと思う。
レガシーと向き合った事例とドメインを見つけ出す作業
レガシーコードと向き合うときにどう取り組んでいったかという話をされていて、DDDをやる上では本当に業務と向き合うということが大事ということを考えさせられた。
動いているプロセスや業務に携わっている人とのヒアリングなどコミュニケーションを重ねることで実現できるジャンルではあるし、別の勉強会で話されていたラーニング・パターンの隠れた関係性を見つけ出すというような思考のテクニックも駆使していくことで理解が深められるんだろうなと感じた。
ドメイン駆動設計の使い手から見るマイクロサービス
ドメイン駆動設計を長年手がけられてきた増田さんが語るマイクロサービスは、Webサービス文脈で語られているアプローチとは異なる部分もあるなと思わせながらも、同じ部分もいくつかあり「必要になったタイミングで分割をはじめる」などは共通の見解なのだなと感じた。
その後紹介されたVETRO分析などは初めて聞いた部分ですし、エンタープライズに身を置く方だからこそ出る観点だし、非常に勉強になった。
増田さんの経験値から来るもの
以前違う勉強会でも話していたが、基本増田さんの話は実体験であり、個人の見解であるという注釈が絶対つけられる。逆にそのポジションを明確にしてくれるので持ち帰る部分と持ちかるべきか考える部分を自身に問いかけることができる。
その自分自身へのキャッチアップすべきかの問いかけがさらなる理解や自身の環境においてどう適用すべきかを考えさせてくれるので良いな、という場面が多いです。
関連リンク
- 混乱しがちなサービスという概念について - かとじゅんの技術日誌 - サービスは混同しがちなのでここを咀嚼しながら整理したい
- PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 - Speaker Deck - 契約による設計と言えばこちらも思い出される
- 契約による設計の紹介 - Hatena Developer Blog
- DevOps, Immutable Infrastructure, Microservices and Chaos Engineering - Speaker Deck - 午前中みたDevOpsとマイクロサービスの話
- マイクロサービスと設計原則 / Microservices and Design Principles - Speaker Deck
全体を通しての感想
普段はBtoCのアプリケーションをやっているので「ビジネスルール」という観点ではなく、企画者の思いつくルールを具現化するという出来上がってない法則に則ってサービスを作っているので、ある種できあがっている業務プロセスを分解するのとは違うことをやっているので、毛色が違うと思う部分も多々ありました。しかしながら自分が普段触れない分野の話なので大変学びが多かったです。また機会があれば次回も参加したいです。(今回は辞退したけど布教用にもう一冊ほしかったです(笑))