ドメイン駆動設計本格入門で学び、そして学びほぐされた #devlove

ドメイン駆動設計本格入門に参加してきました。

講師は増田亨(@masuda220)さんでした。

f:id:dskst9:20190324153527p:plain

概要説明ではなく、開発現場にドメイン駆動設計を導入し、その効果を最大化するための勘所を実コードを使いながら解説します。

とあるように、抽象の話ではなく具体を学ぶことができる講習でした。
以下、講習の中からとくにドメイン駆動設計にフォーカスして内容をまとめていきます。

ドメイン駆動設計本格入門 from 増田亨

www.slideshare.net

ドメイン駆動設計でなぜつくるのか

ドメイン駆動設計でなぜつくるのか。

ソフトウェアの変更を楽で安全にするため。ドメイン駆動設計で変化や成長を呼び込むような設計になる。

逆を言えば、ソフトウェア設計がうまく行っているかの指標は「変更が楽で安全にできるか」と考えることができる。

ビジネスルール自体が複雑ではなく、適用する条件による分岐が複雑である。

ビジネスルールの記述を別のモジュールに分離することで、モジュール群に複雑さが集中する。これだけでも、シンプルになる。

モデルはどこまで行ってもモデルなので現実ではない。
モデルを作るのは抽象というよりは分離ではないか。

ドメイン駆動設計では以下が考えとして大事になる。

モデルは、計算モデルとデータモデルで分かれる。
データモデルはソフトウェアの複雑さに立ち向かう軸ではない。計算モデルこそビジネルルールである。

Fact-Rule-Goal
事実(Fact)を表現し、Factを使った計算や判定のロジック(Rule)により、知りたいこと(Goal)を表現する

プログラミングの表現が、ビジネスルールそのものになる。
値の計算とかで”あったら便利”というものは絶対に作らない。今、確実に必要なものだけを抑えておくこと。

値オブジェクトを用いることで契約による設計を行うことが容易になる。

防御的な検査コードを書かない。
nullを渡さない、返さない。
不正な値を持ったオブジェクトを生成しない

暗黙のビジネスルールの明文化に繋がる。
たとえば、Quentityという型があれば、それに負の値は入らないなど。

区分体型の問題の発見と改善が進む。

区分をenumに落とすと、コードが歪む。歪みに気づくことで区分のリファクタリングを行うことができる。

コレクションをカプセル化することで、コレクション操作が隠蔽されてビジネスの関心事が全面に登場する。

通読するな。パターンをひとつひとつ理解しても役に立たない。

ユビキタス言語: 尺度あって、共通言語として存在することはほぼない。大切なのはあらゆるところにその言葉出る事が大事。
境界づけられたコンテキスト: コンテキストを切ることがゴールではなく、背景にあるコンテキストがどうなっているかを正確に捉えた上で、それが適切なのか、コンテキストを分けたほうがいいかを考えることが大事。
継続的な統合: オールグリーンではなく、チャットやコミットログなどで、ビジネスルール、言葉が使われているかということが大事。言葉として、言葉の理解としての整合性が大事。
コンテキストマップ: データ入出力とかではなく、計算モデルとしてのマッピングである。たとえば、数量というのがコンテキスト単位で違うなどという範囲を表現する。