ドメイン駆動開発のDomain層についてざっくりと。
完全に個人の勉強メモ用です。
※こちらに記述されている表現は、いろいろな捉え方があり「これが正解」という訳ではございません。
基礎概念
基礎となる概念。
ロジックが書かれる場所には2種類ある
- 「使う側(クライアントコード)」と「使われる側」
「使う側」に知識がある場合のデメリット
-
関数の共通化や定数化のみでは、どこでどのように使うのかまでチーム全体で把握できない
- 関数の存在を知らないメンバーが同じような関数を書き始める
- 「使う側」に知識があると、どこでどのように使わないといけないか、をプログラマーが永遠に覚えておかないといけない
- 「使う側(各画面)」で値の加工をしてしまうと、画面Aでは小数点切り捨て、画面Bでは切り上げになったり、単位名がカタカナだったり、アルファベットだったり、ビジネスロジック(仕様)がバラける可能性が高くなる
- 呼び出す時に「これはこう使うんだな」と分かる作りにする必要がある
「使われる側」に知識がある場合のメリット
- 呼び出す時にインテリセンスが効くので、インテリセンスの中から選ぶだけの状態になる
- 知識は「使われる側」に集約されているので、使う側は知る必要がない
これら課題を解決するために
- データ取得後の値の加工を早い段階で行なってあげる
- EntityやValueObjectを使って実装する
Entity
(DDDにおけるEntityは、Clean ArchitectureのEntityとは別の意味になります)
- データを運ぶ入れ物であり、運んでいる値に対するビジネスロジックの置き場所
- ValueObjectを運べるようになる
- 一意生のあるデータのひとかたまり
- SQLなどで取得するデータの1行分
- 型はDBの型を各言語に置き換えたもの
- Entityクラス内でValuObjectクラスに変換する
ValueObject
- 値として扱うクラス
- 完全コンストラクタパターン(必須)
- 値をロジックを一体化させる
- 別インスタンスでも値が同じなら同じものと判断する
- 突き詰めていけばDB項目全てをValueObjectにできるが、ビジネスロジックがないのであれば基本の型でもよい
- 現場でロジックが散らばる原因は、値を基本の型で動かすから
- DBから取得してきたらできるだけ早い段階で、ValueObjectにして値とロジックが一緒になっているクラスに変更することで、ロジックは1つの場所に集約される
- 現場でバグが生まれるのは、値を基本の型で動かすから
Repository(インターフェイス)
- リポジトリは永続化や再構築を担う(インフラストラクチャ)
- DB操作はプログラムの意図をぼやけさせるので分離する
- テスト実行を容易にさせ、変更の難易度を下げる