とっても大切、ドメイン駆動設計
ドメイン駆動設計（DDD）は今の時代に必ず必要となる知識であり、学習するべき価値があると理解しています。
10年以上前に「エリック・エヴァンスのドメイン駆動設計」を読もうとして挫折したものの、しっかり向き合うべきと考え、半年前からこの本を含め、ドメイン駆動設計について学び直しました。
読んだ書籍
エリック・エヴァンスのドメイン駆動設計
原著は20年以上も前の本となりますが、今でもなおソフトウェア開発界隈で、世界的な名著とされています。
抽象的で汎用的な概念としての側面が大きく、具体的なイメージを持ち辛いですが、大切な事が書いています。
巻末のほうに記載があった下記の言葉が特に気に入りました。
オブジェクトはスペシャリストだが、開発者はジェネラリストである。
ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本
「エリック・エヴァンスのドメイン駆動設計」は良書ですが、難解すぎますね。という事で、ボトムアップで具体的なコードを一緒に解説しましょうという目的の本です。
確かにエリック本と比べて具体的でわかりやすいと思います。
コードはC#で書かれているので、C#経験者には理解しやすいでしょう。
私の場合、C#には特に馴染みがないので、後述の【DDD入門】TypeScript × ドメイン駆動設計ハンズオンのほうが分かりやすかったです。
モノリスからマイクロサービスへ
マイクロサービスの設計はDDDと関連が深いので、「エリック・エヴァンスのドメイン駆動設計」を読んだ後にこの本を読むと色々な理解が結びついて良かったです。
ドメイン駆動設計をはじめよう
「エリック・エヴァンスのドメイン駆動設計」より読みやすく、最近の開発現場に即した内容となっています。
「モノリスからマイクロサービスへ」に書かれているような内容も含まれており、これからドメイン駆動設計を学ぶという方にはこの本から入るのも良さそうです。
参考にしたWebサイト
【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
「エリック・エヴァンスのドメイン駆動設計」は具体的なイメージを持ち辛いため、こちらのサイトを元に手を動かして学ぶと理解しやすかったです。
エリック本とこのサイトを行ったり来たりしていました。
モデルをつくり、それを具体的にコードに落とすところまで順を追って学べるので、とても役立ちます。
参考にした動画
10分DDD
技術系YouTube。休日にエリック本を読んだりコードを書いたり読んだりするのに疲れたときの休憩がてら観ました。
1時間以上の動画は辛いですが、15分程度だと区切りやすく、画面共有しているNotionも公開されているので振り返りやすいです。
ドメイン駆動設計は残酷な現実を突きつけてくる
大切なこと、重要なこと
エリック本にしても何にしても、ドメイン駆動で言われている大切なことは業務理解であり、業務がそのままアプリケーションのコードに反映されるべきだということです。
実際にこれは真理だと思いますし、（どこまで出来るかは別として）強く共感します。
「ドメイン駆動設計をはじめよう」が特にわかりやすく、丁寧に価値について言及されています。
- 健全な事業活動、利益を生み出し持続可能な企業は競合他社と差別化された簡単に真似できない中核の業務領域が存在し、この業務ロジックは必然的に複雑になる
- 一般的な業務領域はどの会社も同じやり方なので、独自開発する必要がなくパッケージを導入できる
- 補完的な業務領域は競合他社と同じものにはならないが、ETL（Extract Transform Load）やCRUD（Create Read Update Delete）など単純なものとなる
中核の業務領域はパッケージ導入できるようなものでもなく、複雑なため内製すべき。
一般の業務領域は外部サービスやパッケージを導入すべき。
補完の業務領域は外部委託するべき。
とされています。
ちょっと乱暴な解釈かもしれませんが、「中核の業務領域」の事業の複雑さをシステムとして成り立たせていく以外の単純なETLやCRUDは誰でもできるし、その分価値が少ないので、安い社外リソース使いましょうね。ということです。
どれだけの人がそれを叶えられるのか
ドメイン駆動設計を日常の業務に取り入れられているエンジニアにとって、当たり前で取るに足りない知識・技能レベルを満たす人材の調達も私の観測範囲では人手不足で難しくなっている印象があります。
単純なCRUD処理だけを行うWebアプリケーションを構築する場合も求められる周辺技術や知識は実に様々です。
正しく動作し、妥当性があり、他者にも理解できるコードを主体的に書けるというだけで稀有な存在にも思います。
一方で業務活動の理解がないまま、単純なロジックの実装しかできなければシステムは泥団子にしかならないというのもまた正でしょう。
“作業”というものは急速に価値低下する
ドメインエキスパートと対話し、業務を理解し、モデルを起こし、コンテキストの境界を見極める。
これは容易には成し遂げられないことで、生成AIで単純に代替できるものとは思えません。
一方で、これらの設計が終わった後工程や設計作業の中で発生する細かな単純作業、テストコードの作成、補完の業務領域にあたるETLやCRUDはどうでしょうか。
以前に作業者の仕事はなくなるでも記載しましたが、これらのホワイトカラー職における簡易な業務は機械への代替があっという間に達成されると考えています。
いくら単純なCRUDアプリケーションを正しく作れる人が少なかったとしても、ドメイン駆動設計界隈で言われるようにこれだけでは市場価値が低く、対価を得るのが難しくなるでしょう。
理想像
エンジニアだけでなく、ディレクター・デザイナーも共通言語としてDDDの知識をもち、顧客（ドメインエキスパート）と一緒にイベントストーミングし、モデルを洗練させシステムを構築していく。
そのようなチームが出来れば理想的ですが、前提として持っていおくべき知識が莫大すぎて、とても長い旅路になりそうです。
しかし、「ドメイン駆動設計をはじめよう」の「13章 現実世界のドメイン駆動設計」では勇気を与えてくれる文章が多く記載されています。
幸運なことに、すべての技法を取り入れなくても、ドメイン駆動設計は価値生み出します。
一歩一歩、出来るところから着実にやれるよう頑張っていきたいと思います。