今更読んだエヴァンス本に感銘を受けたので感想書く

こんにちはmofmofでエンジニアをしているshwldです。

最近やっとDDDに入門し、エリック・エヴァンスのドメイン駆動設計を読みました。

色々と知識を深めようとしているのでshwld版ドメイン駆動設計の異本として感想と仮説を書いてみます。

DDDについて感じたこと

DDDには戦略と戦術があります。
戦略は、設計をどうやって行っていくのか、よいドメインをどうやって定義していくか、見つけていくか、蒸留していくかみたいなところ。
対して戦術はコードにどう落とし込むのか、どうしたらドメインを豊かに表現できるのか、変更に強いのか。

ドメイン駆動というくらいだから戦略から入らないとだめなのでは?
よく見たり聞いたりするDDDは全然ドメイン駆動してなくて、戦術（クリーンなアーキテクチャ）の話しかしていない。なぜなんだろう。DDDってそうじゃないと自分は感じたんです。
戦略が重いからとりあえず戦術から入って慣れていくっていうことで推奨してる人もいるみたい。
でもそれも自分はそうじゃないと思いました...

この本めっちゃ重いですよね。
これ全部読んでやってる人、単純に少ないのかな。
プロジェクトでDDDやるってなったときに、戦略の部分が伝わりきらずに、戦術だけをやる人が増えてしまうという構造はとてもあると思いました。

そのあたりもあって、重要そうな戦略について書いてみたいと思ったのです。

そもそもDDDって何なんだろう?

「Domain Driven Design」ドメイン駆動設計の略です。
ドメイン知識とはある専門分野に特化した分野の知識のことです。

本の最初の方に

• コアドメインに集中すること
• ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探究すること
• 明示的に境界づけられたコンテキストの内部で、ユビキタス言語を語ること

という3つが大事だと語っています。

もっとも複雑なのは、システムではなくドメインそのものであるとも言っています。
やっぱりドメインを起点に考えることです。

DDDの思想を反映するときに重要だと思うこと

この思想をどうやって使っていったら良いか。自分が重要そうなところをピックアップしてみました。

ドメインの実践者と開発者の両方が、現在の実装を正しく把握し、改善できる状態を維持すること。

を目的として置くと良い気がします。

これを維持するために、様々なプラクティスを紹介してくれているという風に読みました。
↓それを支えるプラクティスたち

ユビキタス言語

はまさに実践者と開発者感でのコミュニケーションのためにドメインで日常的に使われている名詞を用いるプラクティスであり、コード上にもそれを反映することで認識の齟齬をなくします。
これがこの本で一番重要だと思いました。

ドキュメントと図

ドキュメントと図もまたDDDには必須だと思いました。
ドメインの実装を表現する設計図があることでコミュニケーションがスムーズになります。

設計者と実装者が同じであること

本文でも
「開発に携わる人は全員が、コードを書く必要があり、全員がドメインエキスパートと話をする必要がある。」
といったことが言及されている。

境界づけられたコンテキスト

設計について話していて、同じものを指している別の呼称が登場することがあります。
そういう場合は、それを話す土台（コンテキスト）自体が違うというもの。

自分が作っているアプリケーションにも、ユーザーの視点によって呼び方が違う箇所があり、そこを同じモデルで作っていたために複雑さがましているのだと言うことが予想できるようになりました。
コンテキストが違えばユビキタス言語も違うのだということを知っておくことはとても大切そうです。

しなやかな設計

良いモデルが設計されていれば、モデルを利用して幅広いユースケース（アプリケーション）を表現できる。
逆にいえば、良いモデルがあり、それが隔離されていさえすれば良いはず。

モデルとユースケースの違いというのがすごく難しいなーと感じているんですが、

モデルはルール 。
ユースケースはそれを使った実際のプロセス 。的な理解をしています。

これは極論ですが、ユースケース（アプリケーション）やフロントは別にクリーンじゃなくても良いでしょう。

先程の

設計者と実装者が同じであること

という項目は、最悪モデルの実装に関してだけ行うとしてもみたせるはず。
ユースケースというのはストーリーや仮説検証の数だけ生成されるので、その時々にいちから作ればいいと思う。
大事なのはそのドメインのルール。なのではないか

それを正しく表現し続けるために隔離しておきたい。そう解釈しました。

凝集されたメカニズム

隔離したドメインをより理解しやすいコードに近づけるために必要なメカニズムです。

ドメインとして表現したい「何が」が、「どのように」実現するかの煩雑なコードをにまぎれて読みづらくなってしまう。これを解消するために「どのように」に名前をつけて隠蔽します。

この課題ってDDDでよく聞くものな気がする。なぜそれを書かなければいけないのかわからない（ちゃんと理解するのはすごいコストがかかる。メンバー全員の高い理解度が求められる）煩雑なコードが沢山みたいな。

例を上げるとRailsのActiveSupportなどは凝集されたメカニズムに当たるのだと思う。フレームワークは煩雑なことを名前つけして隠蔽することにより、ドメインをより理解しやすくしてくれる。
Rails自体が凝集されたメカニズムを数多く持ったフレームワークなのでこの観点ではとても強いと思います。

汎用サブドメイン

コンテキストによらず普遍的に使えるドメインがあります。タイムゾーンに関する処理だったり、消費税の計算だったりはそういったものだと思います。それらを外注することでコアドメインを読みやすくできます。

DDDを実践するには

自分がこの本を読んで実践していきたいこと。

• ドメインを起点に考えること
• ドメイン上のルールをモデルに集約すること
• それとユースケースのコードを分離すること
  • インフラとモデルを分離することはユースケースを分離することに比べたら重要度は下がると思いました。どうでしょうか...
    • モデルだけ変えてテーブルマイグレーションせず、無理やりマッピングするのってなんか違くない?
    • 別のDBに移行するとかはそうそう起こるもんじゃないしその時頑張れば...
    • もちろんわけるのが理想だとは思いますが
  • この辺考えたらRailsでも漸進的DDDなら十分やっていけると思った。というかあまりレールを外れる必要はないのではないか。既存のレールを整理すれば。ちょっと構成考えてみよう。

この本すごくない?

自分は今になってやっとこの本に触れましたが、すごく感銘を受けました。

今の開発シーンでは普通に行われていることもたくさん書かれていますが、この本が書かれた時期を考えるとものすごいことだと思いました。
具体的なことがあまり書いてない印象も受けるのですが、設計に関する考え方をここまで言語化しているのはめっちゃすごいなと。
特に第4部の戦略的設計は読みながらテンション上がったのでまた読み直したい。

良いコードの先にある価値あるコードを目指す道だなーと思いました。
どんなフレームワーク、言語を使うにしろこの本は役に立つと思います。

自分は戦略に偏って読んでいたので、戦術はまだあんまりちゃんとわかってないです。
戦術は戦術で試していきたいけど、戦略から入って戦術をつまみ食いするくらいが良いと思ってもいます。

戦略から入るのが重いという意見もありますが、戦略も部分部分で取り入れられるところはありそうなので、アジャイルなプロジェクトなら漸進的にやっていけるのではないでしょうか。

ということでDDDやっていきたい。