天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

じっくり読み解く『ドメイン駆動設計』に参加してきた

modeling-how-to-learn.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

問読/掬読/注釈/音読/段落要約*1の読み方を駆使しながら、エリック・エヴァンスのドメイン駆動設計を読んでいく会です。

前提

  • あくまでもエリック・エヴァンスのドメイン駆動設計を読んでいく書いなので、ドメイン駆動設計とはこうだという話をするような会ではない点に注意が必要だという話がありました。
  • 19:45-21:00までの参加かつ、耳だけ&ながら作業での参加だったので、内容の網羅性は普段のブログよりも低めです

会の様子

会で話があった内容を箇条書きかつ常体で記載していきます。

まえがき

  • ドメインモデリング、設計、イテレーションを通じた進化、ドメイン駆動設計に体系的に取り組むためのフレームワークあたりがキーワードに思える
  • 先進的なソフトウェア設計者とEvansが言っているのが誰か分からない。おそらくKent beckやアンクルボブなんだろうとは思えるけれど、確証はない。ただし、オブジェクト指向開発の先駆者たちという表現が登場することから、Evans自身はこの先進的なソフトウェア開発者に含んでいない
  • ここ20年というのは、1983-2003年の間であることに留意が必要。当時海外ではOOASMALLTALK-80とともに大流行した
  • 哲学という表現には注意が必要。色々な考え方を体系的に考えたいという意図だと考えるとよい
  • 「豊かなドメイン」とはなにか?豊かではないドメインモデルとの違いとしては、このあとに設計のイテレーションを通して進化するものが豊かなドメインモデルとして定義されている
  • 基礎の一部でしかない点には注意が必要。ドメイン駆動設計が実践できたからといって、ソフトウェア開発のすべては網羅できない
  • ある程度の人数が集まっているPJでは、本書の内容を現場に取り入れようと考えるのは現実的ではないと考えられる
  • 成功したプロジェクトに共通する特徴がドメインモデルの豊かさだったという主張があるが、ドメインモデルだけでPJが成功するとはどこにも書いていない

設計対開発プロセス

  • 設計とプロセスは切り離せないという話がある。この記述に共感しているため、設計に一切触れていないスクラム開発プロセスとして語るのに抵抗を感じる。

各部のアウトライン

  • 文章で直接は出てこないが、XPの影響を色濃く受けていることがうかがえる
  • コミュニケーションと設計がドメインモデルとして定義されている
  • アンクルボブのSOLIDはベストプラクティスではあるものの、モデルと実働するシステムとの溝を埋めるような役割が果たせていないというのがうかがえる。同様に、UMLは方法論の統一を試みたがうまくいかなかったと捉えることができるとも言える
  • 標準的なパターンとして、設計と秩序・チームメンバーが互いの仕事をより容易に理解・共通言語に用語法が提供、が挙げられている
  • 意思決定に集中する、というのはValueかと言われるとHowだと捉えている
  • 第二部の内容が土台となっている

会全体を通した感想

多くの知識を持っている方々がそれぞれの知識を総動員しながら曖昧な表現に対して解釈を加えていく様子を観察するのはめちゃくちゃ面白かったです。

また、改めてエリック・エヴァンスのドメイン設計を読んで見ると、だいぶ曖昧な記述や抽象的すぎる話が多くあり、実務に活かす障壁を改めて感じました笑

*1:独学大全の読書手段を参照