https://zenn.dev/hisamitsu/articles/2937fc4dd9bd4c

DDDで開発しようと思って、入門書を勉強して理解した気になっても、いざコードを書こうとすると、なかなか実装のイメージがつかなくて手が止まる、といったケースはあるかと思います。少なくとも、私はそうでした。 この記事では、一旦、DDDのモデリングの部分は置いておいて、コードを実装する上で知っておいた方が良さそうなことをいくつかピックアップして紹介していきたいと思います。いずれも基本的な内容のため、DDDを習得している方にはあまり新しい発見はないかもしれません。 なお、例として用いる言語はTypeScriptです。

DDDで実装してみてなにが良かったか

本題に入る前に、まずはDDDで実装するモチベーションを上げていただくために、実際にDDDで実装してみてよかった点をいくつかあげます。

• ロジックを書く場所に悩まない・チームで統一できる
  • 例えばMVCなど、ドメイン層を用意しないアーキテクチャで実装した場合、ロジックをどこに書こうか悩みが生じます。結果として、チームで開発していると特に、人によってロジックを書く箇所がバラバラになり、統一感の欠けるコードになります。一方で、DDDで実装していれば、まずはドメイン層で書けないかな？という思考が働き、ロジックの分散を防ぐことができます。
• ドメイン層のテストが書きやすい
  • ドメイン層はテストがとにかく書きやすいので、どんどんテストを書きたくなります。ドメイン層のコードはどこにも依存していないので、事前の準備がほとんど不要で、テストしたいことに集中できます。
• ユースケースが理解しやすい
  • ユースケースにロジックを詰め込んでしまうと、見通しが悪くなり、全体として何をやっているかがわからなくなります。DDDでは、ユースケースはドメインオブジェクトのメソッドを呼び出す単純な処理がメインになるので、何をやっているかがコードを見ただけで明確にわかります。
• APIのエンドポイントがORMのエンティティに振り回されない
  • ドメインオブジェクトを用意しない実装の場合、ORMのエンティティを中心とした、DBのデータを取ってきて返す・登録するだけのAPIになりがちです。もちろん単純な要件の場合はこれでも良いのですが、要件が複雑になってくると、呼び出し側の処理が必要以上に複雑になってしまいます。DDDでは、ORMのエンティティとは別に、ビジネスとして意味を持ったまとまりをオブジェクトとして設計するので、結果として、呼び出し側の処理が必要以上に複雑になる現象は起きにくいです。

一応、よくなかった？点も書いておきます。

• 学習コストが高い
• データの詰め替え処理のコード量は増える
• 更新時の処理はパフォーマンスが落ちる
  • 基本的に、DDDではパフォーマンスよりもデータの整合性を重視します。特に、更新時は一発でデータを更新するのではなく、一度selectしてから更新をかける実装になるので、発行するSQL自体は増えてしまいます。

おさえておきたい4つの基本事項

1. ORMのエンティティとは別にドメイン層にエンティティを用意する

ドメインオブジェクトは、基本的にエンティティを使って表現します。エンティティと聞くと、ORMのエンティティが思い浮かぶかもしれませんが、全く別物です。ORMのエンティティは、TypeORMなどの特定のライブラリに依存するものですが、ドメイン層のエンティティはプレーンなオブジェクトで、何にも依存してはいけません。ORMのエンティティにロジックを書く、といった横着はせず、諦めてドメイン層に別のエンティティを用意しましょう。 以下、シンプルな例です。

• ドメイン層のエンティティ

  export default class User {
    id: number;
    familyName: string;
    givenName: string;
  
    constructor(id: number, familyName: string, givenName: string) {
      this.id = id;
      this.familyName = familyName;
      this.givenName = givenName;
    }
  }
  
  

• ORMのエンティティ

  import { Entity, PrimaryGeneratedColumn, Column } from "typeorm";
  
  @Entity()
  export default class User {
    @PrimaryGeneratedColumn()
    id: number;
  
    @Column({ type: "varchar", default: "" })
    familyName: string;
  
    @Column({ type: "varchar", default: "" })
    givenName: string;
  
    constructor(id: number, familyName: string, givenName: string) {
      this.id = id;
      this.familyName = familyName;
      this.givenName = givenName;
    }
  }
  
  

2. リポジトリの取得メソッドはドメインオブジェクトに詰め替えて値を返す

リポジトリの取得系のメソッド（findなど）は、DBから取得した値をそのまま返すのではなく、ドメインオブジェクトに詰め替えてから返します。これにより、リポジトリから値を受け取ったユースケースは、すぐにドメインオブジェクトのメソッドを呼び出すことが可能になります。以下、例です。