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

コードから得られる感覚 (Reading DDD)

DDD

今日の朝活は、DDDの独書会。独りで読む会。ね。

先月、実践DDDを読んで。

bufferings.hatenablog.com

DDD自体をもう一度読んでみようかなと思ってて、今日気が向いた。

さらさらと目次を見て、ここを読んだ。

第3章 モデルと実装を結びつける

偶然だけど、この章は、昨日まで僕が書いてた、僕が好きなコード、との関連が強くて面白かった。
内容に入る前に・・・

パターン・ランゲージ

DDDって「パターン本」なんだなぁ。って思った。

以前に読んだときは、パターン本というものを知らなくて。

一昨年かな?「組織パターン」を読んで。川口さんとかキローさん("川口"と"キロ"って見た目が似てる!)とかに「パターン・ランゲージ」というものを教えてもらって。

あ、そうか。コープ本人の楽天テックカンファでのセッションとかも聞いて(ちょいステマ的な)。

Rakuten Technology Conference 2013: Osaka Satellite やります! #rakutentech - Mitsuyuki.Shiiba

「パターン・ランゲージ」って、「問題」と「状況」とその「解決」のパターン。かな。

僕の中では、「問題を一言で」→「***」で区切られて問題の詳細と状況説明→「それゆえ」からの「解決」→そこから生まれる次の疑問。の流れを見ると「パターン本だな」って感じがする。

他の章がどうかは知らないけど、この章はとりあえずパターンだったなー。

MODEL-DRIVEN-DESIGN (モデル駆動設計)

「モデルと実装を切り離しちゃダメだよ。モデルから実装、実装からモデルへの、ぐるぐるフィードバックが大切だよ。」って感じか。

ふむ。

「設計」という言葉を使ってはるので、「モデル」と「実装」じゃなくて、「モデル」と「設計」と「実装」という感じなのかな。

そうなんだよなぁ。チームの誰か1人だけが興味を持って立てたJenkinsのテストが赤いまま放置されるのと同じくらい簡単に、モデルが同期されなくなっちゃうのだよなぁ。言葉では理解できるのだけど、実際はムズイなぁ。

重大な発見はいつでも、設計や実装をするために努力する際に現れるからだ。非常に特殊で予期せぬ問題というものが常に発生する。

この部分が、まさに、昨日「意味を考えながら書いたら色々気づく」って思ったのと一緒だなと思った。
要件定義も、設計もするけども、僕はずっとコードを中心にしてプロジェクトに関わっていたい。

HANDS ON MODELERS (実践的モデラ)

製造業のメタファからの、このコメント:

高度なスキルを持つ技術者が設計し、それほどスキルのない労働者が製品を組み立てる。このメタファは数多くのプロジェクトを台無しにしてきたが、理由は1つ、単純なことである。すなわち、ソフトウェア開発は、全てが設計なのだ。

わかる。

結局、さっきのと同じで、モデルと実装を切り離しちゃダメだよ。ってことで。

モデリングする人は、モデリングするだけじゃなくて、実際に手を動かして、モデルを反映したコードを書いて、その実装とか制約から得られる感覚を習得して、モデルをより深くしてく。そうしないと、モデルが実用的じゃなくなってしまう。それと、チームに対して、モデルを反映したコードを書いて見せることで、知識とスキルを伝える。チームは、コードとモデルの両方が同期してることを意識するのだ。

って感じか。

ふむ。面白い。