taiyoh's memorandum

@ttaiyoh が、技術ネタで気づいたことを書き溜めておきます。

DDDとClean Architectureの対応関係について

　まず何より、DDDとClean Architectureそれぞれの指向性の違いを把握しておいた方がいいと思う。
　DDDはアプリケーション層（Clean Architectureでいう「UseCase層」）の内部、つまりドメイン層の表現を豊かにするための手法だと僕は捉えている。ドメイン層の独立性の担保のために仕方なく他のレイヤも大雑把に分割している、くらいに思っておいた方がいい。特にインフラ層とプレゼンテーション層にドメイン層ほどの厳密な説明がないのは、DDDが採用される多くのケースはある程度ドメインが見えてきているほどシステムやビジネスが成熟してきている時が（エヴァンス本執筆当時）多かったので、プレゼンテーション層を作り直すようなリファクタリングはドラスティック過ぎるので、アプリケーション層とドメイン層の再分析・再設計に多くのリソースが割かれたからではないだろうか。
　一方のClean ArchitectureはUseCase層（DDDでいう「アプリケーション層」）の外部、つまりFrameworks&Drivers層とInterface Adapters層までいかにユニットテストが書けるくらい責務を分割するか、というところに焦点が当たっていると僕は捉えている。なので、Entities層の独立性や表現云々ではなく、それぞれの責務に応じて機能の分割を行えば、必然的に各レイヤは独立するだろう、くらいのニュアンスではないだろうか。

　僕は上記のような捉え方をしているので、アーキテクチャや実装方針を話す時にDDDの言葉だけで進めると不明な点がたくさんでてくると思うし、業務を正確に理解する時にアーキテクチャに拘ってClean Architectureの言葉でしか話せないと、深い理解にはつながらないと思っている。それこそ両者は似てるとはいえコンテキストが違うので、似た単語が中にあったとしてもあまり緻密な対応付けをしても双方の理解には大きくは貢献しないんではないだろうか。

　因みに僕はDDDとClean Architectureをどう区別しているかと言うと、機能実装をする時にユースケースはDDDの手法を使って分析・記述して、その外側はClean Architectureを意識した実装になるように心がけている。これなら双方のいいところを残せる上に不明瞭な箇所をカバーしあえるので、精度の高い設計や実装を目指すことができるんではないか、と僕は勝手に信じている。

以下は蛇足。