はらだっちのブログ

プロ意識を持ち続ける。その一環として学んだことをこのブログで日々アウトプットしていきます！

エリック・エヴァンスのドメイン駆動設計　1部を読んだ感想

ドメイン駆動設計 読書

はじめに

最近「モデリングがうまくなりたい」、「設計っていったい何なんなのかを知りたい」というところから、UMLモデリング・オブジェクト指向の勉強を経てドメイン駆動設計にたどり着きました。入門書をかじり始めたのですが、同僚から「まずはエヴァンス本の一番重要な第１部を読んでみてほしい」とアドバイスもらったので読んでみました。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

Amazon

読書のモチベーション

DDDのとは何か？を自分なりに理解したい。モデルの探求が出来るようになりたい。設計が出来るエンジニアへとステップアップしたい。

印象に残った箇所

以下、印象に残った部分を書き残しておきます。

UMLで会話していることにびっくり

ドメインエキスパートとＵＭＬで会話してんだな・・・そこまでここにもっていけるのがすごい。そもそもエンジニアでさえ、ＵＭＬ記法を理解している人は少ないと思う。かくいう私もこの前まで理解していなかったうちの一人でした。

旧来のウォータフォール型と今自分たちがやってるアジャイル開発との対比

  • 「ビジネスエキスパートがアナリストに反し、アナリストがかみ砕き抽象化し、プログラマに伝える」
    • この構図はめっちゃわかる。SIer時代はほんとこれでした。
  • 「フィードバックループが無いから知識は一方向に流れるだけで蓄積されない」
    • 今アジャイル開発をやっているつもりだけど、すごく今の私たちの活動の状態を表してる一文な気がする。。。うーん、自分たちはやはりなんちゃってアジャイルになってる？
  • ドメインモデルはドメインエキスパートと開発者を近づけるもの
    • これを握ることで双方が正しい方向へ向かい始める
      • ドメインエキスパートは抽象化してより重要なことを伝える努力をする
      • 開発者はビジネスを動かす重要な原理を習得するように強いられ、機械的に機能を作ることがなくなる

輸送業のモデルの例

  • 元々は荷物のある場所を別の場所に移動する、その時の日時を管理する、ためのモデルを作ってた。よくよく来てると、実はいろんな会社が輸送には介在してて発注者が管理したい対象は日次ではなかった。
  • 最終的には、各会社間での責任の移動を扱うモデルだった。

すごいあるあるな話な気がしました。モデルの本質を見極めることの難しさはここにあると感じました。

モデルを言語の骨格として使用すること

  • ユビキタス言語における変更は、モデルに対する変更であると認識すること
  • 「問題が発生するのは、モデルや設計の全体を伝えるのに、UMLを使うことを強いられていると人々が感じた時である。」
    • めちゃ分かる。”設計書としてUML図を書かなきゃいけない”となった時点で、UML図作成の目的を見失ってしまうと思う。

UML図で表現できないこと

  • ＵＭＬ図はモデルの最も重要な側面のうち２つが伝えられない。自然言語を慎重に使用することで回避する
    • モデルがあらわしている概念の意味
    • オブジェクトが何を行うことになっているか
  • ＵＭＬをプログラムを書ける技術として使うとモデルの意味そのものが失われる

いやー、これも分かる。目的・概念が重要なのにいつの間にか失われる。。。

設計ドキュメントについて

  • XPはコードですべてを表現する。動作しているコードのふるまいにはあいまいなところがないから。
    • すでにコードがうまくやってることをドキュメントでもやろうとすべきではない
  • モデルは形式ばらないその場限りのもの
    • これは今後意識していきたい。

XPも学ぶ必要がありそう（自分の理想に近そうな開発手法な気がするので）。

設計ドキュメントの持つ最大の価値

  • モデルの概念を説明すること
  • コードの詳細を書き進める上で役立つこと
  • モデルで想定されている使用方法について多少の洞察を与えること

モデル駆動設計について

  • モデルは一つに（分析と設計それぞれでモデルを作らない）。
    • この記述はすごくすっきりする。今までＵＭＬを学ぶときに分析モデルと設計モデルが分かれていることに違和感を感じていた。 　また、UMTPを取得した後、ついつい「設計のやり方の基礎が身につきました」と言って「あれ？身に着いたのは設計じゃなくてモデリングか？」みたいなことも感じてた。切っても切り離せないモノってことなんだな。
  • 複雑なデータ型をサポートする言語は、ドメインにおけるより自然な概念との一致が見られ始めている。しかし、複雑なデータ型はデータをまとめたものでしかなく、ドメインの活動的な側面は捉えていない。

感想

自分の現在のエンジニアレベルを客観視した

私は2年前に転職しフロントエンジニア３年目なのですが、転職した時点では「Reactって何？」、「Typescriptって何？」、「オブジェクト指向ってあれでしょ、継承とかカプセル化（用語しかしらない）」というレベルでした。そこからアジャイル開発とは？という開発手法から入り、JavascriptによるNext.js開発を経てフロントエンジニアの素養を養ってきました。直近半年ではモデリングの重要性を感じ、UML(UMTP)やオブジェクト指向について学びを深めてきました。

その結果、兎にも角にも何が書いてあるかは今のところほぼ理解できています（本来の意味で理解できたかは別だが）。この手の立派な技術書は中々読み進めるのが苦手なのですが、事前にUMLの勉強をしていたおかげで、紹介されるクラス図や相互作用図に対して拒絶することが無かったです。2年前よりは確実にエンジニアリングスキルが身についてきてると感じました。

本の内容自体も、著者が実際に経験したプロジェクトの中から具体例を交えて説明しているので、比較的頭に入ってきやすい構成になっていると思いました。

普段の仕事の進め方の反省になった

普段、私は業務プロセス図やワイヤーフレーム、ERDやDFDを使用しています。これらはモデリングに近い位置づけのものと感じていただが、ドメインモデルと比較して、図の使い方に違いがあると感じました。

  • ユビキタス言語を意識してモデリングに取り組んでいない
  • モデルと設計・実装が密接に関連しているように感じられない

また、業務プロセス図についてはドメインエキスパートとともに作成してきた感はありますが、 クラス図やERDを一緒に作成してきたわけではないので、設計が業務的振る舞いを正しく表せているのかは疑問に思ってきました。ダイアグラム自体はある程度練りあがっていることもあり、これをビジネスサイドの人たちに急に見せて議論して善しあしを判断するのも中々難しそう、と感じました。その点を踏まえて荒、MVPを早く作ってコードに知識を蓄積していった方がいいかもしれない、とも感じました（UIもコンソールベースの業務ロジックにする、とか色々やりようはありそう）。

終わりに

うーん、本質な理解には程遠いですね。何度も読み返して一歩ずつ理解していけたらと思います。