「ドメイン駆動設計とYAGNIの原則は共存するのか？」に関しての考えをまとめました。

目次

この記事はOpenAIを用いて作成したものに加筆修正を加えたものです

ドメイン駆動開発は、依存性注入やインターフェースを用いて、結合度を下げることが目的の一つです。 役割ごとに抽象化することで、保守や再利用を容易にできます。

一方で、最近クラスへと切り分ける作業を行いました。このときにためらってしまう要因がありました。

• これはYAGNIの原則から違反しているのではないか
• 逆にわかりにくくないだろうか。保守性は高いのだろうか

こういった疑問を解決したく調べてみました

概要

ソフトウェア開発において、適切な設計を行うことはプロジェクトの成功に欠かせません。ドメイン駆動設計（DDD）とYAGNIの原則は、開発者が効率的で柔軟なコードを作成するための鍵となります。この記事では、ドメイン駆動設計とYAGNIの原則の関係性について解説します。

ドメイン駆動設計（DDD）

ドメイン駆動設計は、ソフトウェアのコードをビジネスドメインに基づいて構造化する設計手法です。このアプローチにより、コードはビジネスの要件やドメイン知識に忠実になります。例えば、メタデータを管理するクラスを開発する場合には、以下のようなステップを踏むことが考えられます。

// メタデータを管理するインターフェース
interface MetadataManager {
    // 入力値のバリデーションを行う
    public function validate(): bool;

    // 入力値を加工してパラメータを作成する
    public function createInputParams(): InputParams;

    // 加工された入力値をcanonicalにする
    public function makeCanonical(): CanonicalData;

    // 加工された入力値からタイトルを作成する
    public function makeTitle(): string;
}

YAGNIの原則との関係

YAGNI（You Ain’t Gonna Need It）の原則は、不要な機能や実装を行わないことを意味します。これは、 「使わない可能性が高いものは最初から実装しない」 という考え方です。

ドメイン駆動設計においては、将来の拡張性を考慮してインターフェースを切り出すことがありますが、それは必ずしもすべての場合に適しているわけではありません。YAGNIの原則を念頭に置きながら、「将来的に必要になると予測される機能に対してのみ」インターフェースやDIを導入することが重要です。

もし、メタデータ管理クラスが一度だけ使用される場合や、将来の拡張性が低いと判断される場合は、無理にインターフェースを導入する必要はありません。必要に応じて適切な設計を選択することで、無駄なコードや手間を回避し、より効率的な開発を実現できます。

ドメイン駆動設計とYAGNIの原則は、ソフトウェア開発において留意すべき重要な考え方です。プロジェクトの要件や将来の見通しをよく理解し、具体的な利益とコストを考慮しながら、適切な設計手法を選択することが成功への道筋となるでしょう。