ドメイン駆動設計（DDD） とは？

開発者とビジネス担当者が同じ用語を使うこと。ビジネス側が「注文」と呼ぶものをコードでもOrderクラスにする。「承認」はApproval、「請求」はInvoice。コード内の変数名やクラス名が業務用語と一致していれば、仕様の認識齟齬が減る。「内部的にはdataItemだけど業務的には注文」みたいなのはNGだよ

同じ言葉でも文脈によって意味が違うことがある。「商品」は販売部門では「売り物」、物流部門では「配送対象物」、会計部門では「売上項目」。これらを1つのProductクラスにまとめると複雑化する。部門ごとに境界（コンテキスト）を定めて、各コンテキスト内で最適なモデルを設計するんだよ

境界づけられたコンテキストがマイクロサービスの分割単位の有力な指針になる。販売コンテキスト→販売サービス、物流コンテキスト→物流サービス。技術的な分割（DB層、API層）ではなく、ビジネスドメインで分割するのがDDDの考え方。これにより各サービスが自律的に開発・デプロイできるようになるよ

DDDの戦術的パターン（エンティティ、値オブジェクト、集約など）をいきなり全部適用しようとすると挫折しやすい。まずは戦略的パターン（ユビキタス言語、境界づけられたコンテキスト）から始めるのがおすすめ。「業務用語でコードを書く」「チームの言葉を統一する」だけでもDDDの恩恵は大きいよ