冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

中国DB勉強会でDDDの話をしてきた

はい、そこデータベース関係ないじゃん、とか言わない、自分でもわかってます。久しぶりにセッションスライドを公開します*1

背景

事前の告知通り、本来は原田さんに担当していただく予定だったのですが、ちょっと前から体調を崩されていたため、曽根さんと相談してハンズオンとセッションを分担することにしました。原田さんのぐるぐるDDDを楽しみにしていらした方は申し訳有りません。

今回のセッションのゴール

  • Not ポカーン
  • DDDを読む、知るきっかけにする
  • その後のハンズオンで迷わない内容

改めてDDDについて思ってること

私にとってDDDに最も強く感じている価値は、パターンランゲージであることです。

パターンランゲージは、生き生きとした場(街)を作ることを目的としながら、目的が抽象的にしか指し示すことができないため *2 、行為と行為を促す状態に焦点を当てた手法だと思っています。

良い設計というのも同じだと思っています。「良い設計」という表現で具体的なアーキテクチャコンポーネントの配置などを思い浮かべる人はいないのではないかと思います。保守性だとか運用容易性だとか、コードやドキュメントの可読性だとか、モデルのできだとか、そんなこんなをソフトウェアが提供される文脈に基づいて取りまとめて、良い状態であれば「良い設計」なんです。抽象的です。でも、この状態が開発者やドメインエキスパートに何をもたらすか、というのは、ほぼ暗黙的に共有されているのではないかと思います。

我々は「良い設計」を目指さなければならない、しかし具体的に「良い設計」を指し示すことができない、という所から出発して設計を突き詰めようとした場合に、DDDがパターンランゲージの形を取ったのは必然だったのではないかと思っています。というわけで、私がDDDについて話すときは、だいたいこういう話っぷりになるわけですね。

何度読んでも発見がある本

今回、セッションに向けて改めてDDD本を読み返しましたが、パターンランゲージナレッジマネジメントに興味を持ち始めてから読むと、また新たな発見がありました。合同勉強会辺りのポカーン枠で活かせると良いなあ。

*1:しばらくスライド公開しても意味ないものが続いてたので

*2:暗黙的に共有、理解されていると言っても良いかと