Domain Driven Design で Evans の言う「設計」って何? #kandddj

「関西DDD.java スタートアップスペシャル」に行ってきました。

会場は楽天の大阪支社ですん。kansaiddd.connpass.com

まとめはこちら

togetter.com

増田さんがEvansのDDD本の全17章を解説

だいたい、僕が事前に読んだときの理解と近い感じだったので安心しました。bufferings.hatenablog.com

まぁ、理解と実践の間にはひどい壁があるから、これからね。

「チームで取り組まないといけない」

印象に残ったのは。「チームで取り組まないといけない」という言葉。何回も出てきた。

これが、僕、すごく苦手なんですよね。啓蒙というかエバンジェリストになるというか。そういうの。

そういうとこダメだとは最近思ってる。

でも、「ぐいっとやるときあるよ。俺は。」みたいなことも仰ってたので、安心もしつつ。

懇親会で増田さんに質問

Evansの言う『設計』というものが何を指しているか、いまいち確信がもてないです。


DDDを読んでたら『モデルをコードに起こすこと』を『設計』と呼んでるっぽいんですけど、明確に言及してないんですよね。日本だったら概要設計書や詳細設計書を書くことが『設計』にあたるのかな?と思うんです。


Evansは何を指して『設計』と言っているんでしょうか?

増田さんからはこんな感じの回答をいただきました。

オブジェクト指向の世界では、モデルをコードでどうやって表現するかを考えることが「設計」、実際にコードを書くことを「実装」と呼ぶんですね。


手続き型の実装だとモデルとコードの間に、それを説明するためのものが必要になったりするから、それを設計と呼んだりしますね。でも、オブジェクト指向だとモデルをそのまま表現しようとするので、コードでどのように表現するかを考えることを「設計」と呼びますね。

ということで、なんかスッキリしました。Evansにとっては自明なことだから説明がないんでしょうね。フムフム。

懇親会で「ドメインエキスパートはどこにいるのか?」

やまねさんやいろふさんと「ドメインエキスパートっている?どこに?」「きっといないよ!」とか、「ユーザーストーリーマッピングとDDDとスクラムとXPはさぁ」とかであーだこーだ話をしたり。

んで、はるじっくさんと、「帳票生成ロジックはアプリケーションレイヤーにおくよね?」とか、「じゃ、帳票の明細部分が大量な場合って、同じ集約にできないから、技術的理由から分ける?」とか、「集約同士の整合性を取るために、間に整合性を運ぶためのオブジェクトを置いて両方のトランザクションで触る?それか整合性を運ぶためのイベントを飛ばして結果整合性を取る?」とかでごにょごにょ話をしたり。

5年前のGoogle IOで椎葉さんと話をしたことがあるよーって方がいて、「えー!?」って驚いたりで。

すごい楽しかった。

みなさん

ありがとうございましたー!