なにそれ？

その名の通り、DDD(ドメイン駆動設計)と最も相性がよいと考えられる「プログラミングレイヤー」のアーキテクチャです。いわゆる「クリーンアーキテクチャ」に着想を得ていますが、原理はよりシンプルです。

モチベーション

DDD本は神！ではあるんですが、、、

DDDといえば、エリックエバンス。みなさんも「エリックエバンスのDDD本」大好きですよね？

エリックエバンスのDDD本は、2020年代の今においても全く色褪せない本質を我々に伝えてくれる名著ですが、一点だけ物足りない部分があります。

それは、DDD本の中で紹介されている「プログラミングレイヤーを設計するにあたってのアーキテクチャ」がイケテナイという点です。これって「さあドメインモデルはできた！実装するぞい！」っていうときに一番大事になるものですよね。
一応、当時は新しかった(?)レイヤードアーキテクチャが載っていますが、これに従ってもドメイン知識を正しくソースコードに適用し続けるという運用上の課題は解消されません。このため、DDD本だけでは「快適ににプログラミングし続ける世界」が訪れないのです。

これはなぜかといえば、ドメイン層がインフラストラクチャ層に推移的に依存してしまうという「ドメイン駆動」的には一番やっちゃいけないことをやってしまっているということに尽きます。当時はまだコンピュータリソースも相当カツカツだったでしょうし、色々事情があったんだとは思われますが。。。

先人たちの改善の歴史がそこにある、だがしかし

その後、この点を改善すべく「ヘキサゴナルアーキテクチャ」->「オニオンアーキテクチャ」->「クリーンアーキテクチャ」と進化してきた系譜がありますが、これらは本質的に同じものです。つまり、「依存性の逆転」というテクニックを用いることで、上述のやっちゃいけないことを回避しているというところがポイントになります。

ところがです。ここがドメイン駆動アーキテクチャを提案する最大のモチベーションといっても差し支えないのですが、これら3つは全く同じ「誤り」を犯して しまっており、たとえこれらのアーキテクチャを教科書通りに実践しようとしても、どこかでもやもやしたものを抱えながら進むことになります。

そこ間違えるなんてことある？？

それらが犯してしまっている誤りがどこにあるのか、を一言で言うならば 「全ての依存が中心の層に向かい、逆に中心から外の層へは依存しない」 という構造の部分です。実のところ、これはよく考えるば論理的におかしなことが起きているのですが、ここの誤謬に言及するような書籍はブログは今まで見かけたことがありません。

この論理的混乱のせいで、せっかく思想としては素晴らしいアーキテクチャであるにも関わらず、実際に実装をするときにこの(暗黙的な)矛盾が解消されず、アーキテクチャが形骸化するということが起きてしまっています。

そこで、ドメイン駆動のメリットとそのその実践を最大化すべく、この5年くらいウンウン考えてきたことの成果に 「ドメイン駆動アーキテクチャ」 などという大上段に立った名付けをしてご紹介しようというのが本記事の目的になります。

WIP

• クリーンアーキテクチャの誤りとは
• じゃあどうすんの？
• 最低限必要な要素
• 具体的な実践方法
  • ディレクトリ構造とlintで依存を徹底的に制約する
  • Backend / Frontend それぞれの設計
    • Domain
      • Entities
      • UseCases
        • frontのusecase設計はむずい
    • なにをインフラとみなすべきか
    • Adapter