バックエンドTypeScriptでオニオンアーキテクチャを運用してわかった手応えと反省点

CRANK

弊社ではT3-Turboを導入しており、フロントエンドにNext.js、サーバーサイドにNestJSを採用しています。本記事では特にサーバーサイドのアーキテクチャに焦点を当て、私たちが実践しているドメイン駆動設計（DDD）について、その運用から見えてきたメリット、デメリット、そして今後の課題を考察・共有します。1. アーキテクチャの全体像弊社ではDDDの実現方法としてオニオンアーキテクチャを採用しています。クリーンアーキテクチャではなくオニオンアーキテクチャを選択した理由は、後者の方が usecase（アプリケーション層）と domain（ドメイン層）の境界がより明確 であり、「ビジネスの関心事をドメインとして独立させる」という私たちの設計思想と強く合致したためです。特に、オニオンアーキテクチャがドメイン層からアプリケーション層への依存を許さないという原則は、私たちが目指すドメインの純粋性を保つ上で非常に重要でした。まず、弊社におけるオニオンアーキテクチャの具体的なディレクトリ構造を以下に示します。. ├── utils ├── usecase └── domain ├── entity │ └── value-object ├── repository └── service …