2025/11/15 23:45 If You Apply DDD to DDD, You Won't Get DDD
ロボ子、今日のITニュースはドメイン駆動設計（DDD）についてじゃ。
DDDですか。ビジネスドメインに集中して、より良いソフトウェアを作るという設計思想ですよね。
そうじゃ。でも、記事によると、DDD自体をもっとシンプルに考えるべきらしいぞ。
どういうことですか？
DDDは2003年からあるのに、まだ主流じゃないじゃろ？
確かに、一部のコミュニティに限られている印象があります。
記事では、その理由の一つに、集約とか境界づけられたコンテキストみたいな難しい概念が多すぎると言っておる。
概念が先行して、本質が見えにくくなっているということですね。
そうなんじゃ。「開発者はパターン（集約、境界づけられたコンテキストなど）を学ぶことがDDDであると信じている」と。
DDDは、ビジネスドメインに焦点を当て、ドメイン専門家との共通言語を開発することが目的ですものね。
記事には「DDDは本質的に非技術的」とある。ドメイン専門家との対話が大事なんじゃ。
たしかに、技術的なパターンにばかり気を取られていると、ドメインの本質を見失ってしまいそうです。
「パターンは、人々との対話の代わりに集約やエンティティについて議論したり、ドメインを理解する代わりに境界づけられたコンテキスト図を描いたりするなど、隠れ場所を提供する」か…耳が痛いエンジニアも多いんじゃないかの。
図を描くこと自体が目的になってしまうのは、本末転倒ですね。
DDDを学ぶには、パターンを忘れて、ドメイン専門家との会話を学ぶべきじゃな。
記事では、イベントソーシングがDDDへの軽量なエントリーポイントになるとも言っていますね。
イベントソーシングは、ビジネスで実際に何が起こったのかを記述する必要があるから、ドメイン言語に近づかざるを得ないんじゃ。
イベントをサブジェクトに編成することは集約の議論に、どのサービスがどのイベントを処理するかを決定することは境界づけられたコンテキストの議論になる、と。
つまり、イベントソーシングを入り口にすると、自然とDDDの概念に近づけるってことじゃな。
DDDを実践する際は、ドメイン専門家との時間と図を描く時間のバランスを意識することが大切ですね。
そうじゃ。コードがビジネスの言葉を話しているか、CRUDじゃなくてイベントとドメイン動詞を使っているか、常に自問自答するんじゃぞ。
肝に銘じます！
ところでロボ子、DDDって、なんだかダイエットみたいじゃな。
どうしてですか？
最初は色々な方法を試すけど、結局はバランスの取れた食事と適度な運動が一番大事！…って、ちょっと違うか。
あはは。確かに、本質を見失わずに、シンプルに考えることが大切という点は共通していますね！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
