読者です 読者をやめる 読者になる 読者になる

第五回ドメイン駆動設計読書会@大阪に参加した

5回目。 固定メンバーでの勉強回ということもあって流石に馴染んだ感じある。

今回はモデル駆動設計へと続く大事な章。 勇んで独断と偏見による感想文で他を圧倒するしかと思ったけどレポートが素晴らしすぎて鼻血出た。ここに今回の全てがあります。@sugimoto_keiさん、いつこれだけのメモを...?

個人的なハイライトは以下だった。

具象から抽象へ

僕達みたいなソフトウェアエンジニアは、顧客の要求を解決するため、日々その要求に対して向き合っている。これは、場をエンタテインメントに移した場合でもそんなに変わらなくて、要するにユーザーに価値を提供すること、つまりソリューションの提供を目的としているはず。

このソリューションの提供までには、様々な人が多種多様なコンテキストを持ってゴタゴタ進んでいく。DDD本を読んでいて、ここでまず重要になるのが「要求」と「ユビキタス言語」だということに気がついてきた。

最も重要なことは「要求」。理由は、これがゴールとなるから。 要求をなるべく正確に得るためには、「分析」することが必要になる。 分析とは、ドメインエキスパート(ユーザー)からドメインの知識(要求)を抽出することだと思う。 ただ気をつける必要があるのが、ドメインエキスパートも我々も、この時点で実は正しい要求を持っていない場合が多いんじゃないかと思う点。つまり、この時点で詳細には分析出来ないはず。普通は。

じゃどうするかというと、まずはざっくり。なんかドメインエキスパートの人が言ってるから取り敢えずそれを実装しちゃう。ここが本当のスタート地点なんだと思う。 とにかく動かす。実はここに全力を傾けるべきだったんじゃないか?

僕はこれまで結構分析してた。 いるかどうかもわからない機能を考慮したり。 思い込みの塊に時間を費やしたり。 初めから色々考慮しとくと後が楽だろう?!みたいな。

まぁこれが悪いとかは無い。ただもっといい方法があったという話。

この動くもの。これは具象。誰が見てもそう。 まずはこの具象を持ってもう一度「要求」について話合うことが必要だと思う。ここで本格的に登場するのが「ユビキタス言語」じゃないかと。そしてこの「要求」を「ユビキタス言語」で表したものを「モデル」と呼び、この行為それを「分析」と呼ぶ。 この過程でモデルは何れかの「ドメイン」に紐づいていく。

これは「モデル駆動設計」と呼べそうだ。 この過程は、様々なものが具象から抽象へと昇華している。すごく自然な形だと思う。 5回の読書会で得られた理解は今ここ。

明日から使える!的なものとしては

「とにかくいいから動くもんを最速で作れ。話はそれからだ。」

これを補う技術領域がCI、TDD、リファクタリングなんだろうなーという感じがしている。