DDDと一緒に考えるアーキテクチャ

memo / 思ったこと

DDDの思想

「複数のコンテキストがあれば、それぞれのコンテキスト内でユビキタス言語を定義する」というDDDの思想がある。
例えば、ECサイトの「オーダー」は、人によっては「顧客の注文」と捉えるが、現場によっては「倉庫の出荷リスト」と捉え意味が違う。SNSの「ユーザー」は、「それを使う一般ユーザー」と「そこで広告を出す企業アカウント」といった意味のユーザーもある。分かりやすく言うなら、ある一つの単語は、場所や人の受け取り方で考え方が全く異なることのことを言う。つまり、同じ言葉でも、コンテキストごとに意味が異なるため、個別にユビキタス言語(共通の言葉)を定義する必要がある、ということだ。

クリーンアーキなりオニオンアーキなり

クリーンアーキテクチャのど真ん中には「エンティティ層」があるが、エンティティ層の責務は、

Enterprise wide business rules “企業一般で適用できるビジネスルール“

と書かれている。つまり、上記のDDDの思想である、｢複数のコンテキストに対してそれぞれのコンテキスト内でユビキタス言語を定義する｣思想と合致していない。(ちなみにオニオンアーキはエンティティ層ではなくドメイン層とされいている。DDDではドメインオブジェクトが一種のエンティティでもある。というのもあって↓↓)

それを考えると、DDDの思想に合っているのはオニオンアーキテクチャなのかなと。コンテキスト毎に定義を分け、それをソフトウェアで表現するためには内部から分ける必要があるのがDDDの思想。であれば、オニオンアーキテクチャの思想を当てはめることが出来、かつ「1コンテキスト1アプリケーション」、つまりはマイクロサービスになるイメージができる。実装的にはだいぶコスト高いと思うが。とはいえそこを曖昧にしすぎても複雑になって継続的な開発がしにくいのもあると思うので、いい塩梅を見つけ最適解を模索しながら開発する、だから強いBEエンジニアは必要だし、企業として技術負債を0とするのはほぼ不可能なんだと思う。超持論ですがね。