今日の朝活は、DDDの独書会。独りで読む会。ね。
 エリック・エヴァンスのドメイン駆動設計 |
先月、実践DDDを読んで。
DDD自体をもう一度読んでみようかなと思ってて、今日気が向いた。
さらさらと目次を見て、ここを読んだ。
第3章 モデルと実装を結びつける
偶然だけど、この章は、昨日まで僕が書いてた、僕が好きなコード、との関連が強くて面白かった。
内容に入る前に・・・
パターン・ランゲージ
DDDって「パターン本」なんだなぁ。って思った。
以前に読んだときは、パターン本というものを知らなくて。
一昨年かな？「組織パターン」を読んで。川口さんとかキローさん("川口"と"キロ"って見た目が似てる！)とかに「パターン・ランゲージ」というものを教えてもらって。
あ、そうか。コープ本人の楽天テックカンファでのセッションとかも聞いて(ちょいステマ的な)。
Rakuten Technology Conference 2013: Osaka Satellite やります！ #rakutentech - Mitsuyuki.Shiiba
「パターン・ランゲージ」って、「問題」と「状況」とその「解決」のパターン。かな。
僕の中では、「問題を一言で」→「***」で区切られて問題の詳細と状況説明→「それゆえ」からの「解決」→そこから生まれる次の疑問。の流れを見ると「パターン本だな」って感じがする。
他の章がどうかは知らないけど、この章はとりあえずパターンだったなー。
MODEL-DRIVEN-DESIGN (モデル駆動設計)
「モデルと実装を切り離しちゃダメだよ。モデルから実装、実装からモデルへの、ぐるぐるフィードバックが大切だよ。」って感じか。
ふむ。
「設計」という言葉を使ってはるので、「モデル」と「実装」じゃなくて、「モデル」と「設計」と「実装」という感じなのかな。
そうなんだよなぁ。チームの誰か1人だけが興味を持って立てたJenkinsのテストが赤いまま放置されるのと同じくらい簡単に、モデルが同期されなくなっちゃうのだよなぁ。言葉では理解できるのだけど、実際はムズイなぁ。
重大な発見はいつでも、設計や実装をするために努力する際に現れるからだ。非常に特殊で予期せぬ問題というものが常に発生する。
この部分が、まさに、昨日「意味を考えながら書いたら色々気づく」って思ったのと一緒だなと思った。
要件定義も、設計もするけども、僕はずっとコードを中心にしてプロジェクトに関わっていたい。
HANDS ON MODELERS (実践的モデラ)
製造業のメタファからの、このコメント：
高度なスキルを持つ技術者が設計し、それほどスキルのない労働者が製品を組み立てる。このメタファは数多くのプロジェクトを台無しにしてきたが、理由は1つ、単純なことである。すなわち、ソフトウェア開発は、全てが設計なのだ。
わかる。
結局、さっきのと同じで、モデルと実装を切り離しちゃダメだよ。ってことで。
モデリングする人は、モデリングするだけじゃなくて、実際に手を動かして、モデルを反映したコードを書いて、その実装とか制約から得られる感覚を習得して、モデルをより深くしてく。そうしないと、モデルが実用的じゃなくなってしまう。それと、チームに対して、モデルを反映したコードを書いて見せることで、知識とスキルを伝える。チームは、コードとモデルの両方が同期してることを意識するのだ。
って感じか。
ふむ。面白い。
