DDDの原則とDDDの問題点に関する会話

杉本啓 @sugimoto_kei

エヴァンスさんの話はわかりやすい。分析モデルと設計モデルの統合というのは、達成出来ないけれど追求すべき目標だということと思う。聖杯なんだ。

杉本啓 @sugimoto_kei

「僕にとって、ドメインは、形態、つまりアーキテクチャに関係している。用途は、おおむね、（それに）直交している」 twitter.com/jcoplien/statu…

James Coplien @jcoplien

@sugimoto_kei @ericevans0 @cactaceae @hidenorigoto To me, domains relate to form, which is architecture. Utility is largely orthogonal. #MPD

2016-12-25 09:58:33

杉本啓 @sugimoto_kei

このコプリンさんの話は、解釈が難しいぞ(-｡-;

Atsuhiro Kubo @iteman

後藤さんのツイート twitter.com/hidenorigoto/s… twitter.com/hidenorigoto/s… から、リーダーたちの議論になるとは。これが Twitter の醍醐味だな。

Hidenori Goto | COO and CTO at KabuK Style @hidenorigoto

ドメインレイヤーのクラス群は外部の道具を使っちゃダメ、ピュアにしろ！ってのは、割りと昔から私には納得できない話の1つだ。私は、ドメインモデルを表現するために積極的・明示的に道具を使う。それが普通だと思うし、おかしいとは思えない。

2016-12-17 18:32:57

Hidenori Goto | COO and CTO at KabuK Style @hidenorigoto

@cactaceae なるほど。IDDDの方はまあまあ読みました。ちなみに私が求めてるものは、 twitter.com/jcoplien/statu… このtweetに対する回答がビシっと書いてあるくらいのものを期待してます。

2016-12-21 00:58:24

Atsuhiro Kubo @iteman

@sugimoto_kei ここでは utility は実用性、有用性の方がしっくりくるように思いますが、いかがでしょうか。

杉本啓 @sugimoto_kei

@iteman そんな感じもしますね。その実用性を具体化したらユースケースってことで、いいんですかね？

Atsuhiro Kubo @iteman

@sugimoto_kei タグが #MPD となっていますので、2つの文の前者は、問題の構造に基づいた第1レベルのアーキテクチャ github.com/phpmentors-jp/… だと思いますが…

Atsuhiro Kubo @iteman

@sugimoto_kei …後者はわかりません。MPD 本でデザインの次元（データ構造、手続き…）が直交していることは何度か言及がありましたが。

杉本啓 @sugimoto_kei

.@hirok_tkh @iteman 翻訳しなかった部分のやり取りを読んで、ちょっとわかってきました。翻訳ツイート流します。

杉本啓 @sugimoto_kei

「実装は詳細設計だ。だから、言葉を変えれば、実装と分析には直接的なつながりがある」 twitter.com/cactaceae/stat…

r.ishibashi @cactaceae

.@jcoplien @ericevans0 Implementation is detailed design, so in other words, direct connection between implementation and analysis.

2016-12-22 10:26:01

杉本啓 @sugimoto_kei

「ゲトルードと僕は、最近、なぜそうではないかを、分かり易く解説するコース教材を開発した。こういうユーザーストーリーを考えて欲しい...」 twitter.com/jcoplien/statu…

James Coplien @jcoplien

@cactaceae @ericevans0 Gertrud and I recently developed some course materials that illustrate why this is not so. Consider user stories...

2016-12-22 19:18:16

杉本啓 @sugimoto_kei

「...３つの別個のユーザーロール（訳注：役割）がある。―プロダクトに対して、あるひとつの修正をすれば、それぞれのロールは各々異なる便益を受ける。その便益をプロダクトバックログに入れるとしよう」 twitter.com/jcoplien/statu…

James Coplien @jcoplien

@cactaceae @ericevans0 ... for 3 distinc user roles—each role benefits differently from one product increment. Put them on a Product Backlog

2016-12-22 19:20:03

杉本啓 @sugimoto_kei

「バックログは1件のアイテムを含むことになるのだろうか。それとも3件か。ススクラムでは、バックログにはプロダクト修正差分を含めるのであって、要件を含めるのではない。というのは...」 twitter.com/jcoplien/statu…

James Coplien @jcoplien

@cactaceae @ericevans0 Does the backlog contain 1 or 3 items? In Scrum the backlog contains Product Increments—not requirements, because...

2016-12-22 19:20:48

杉本啓 @sugimoto_kei

「...分析的な視点を実装に変換するにあたっては、かなりのプロセスが介在するからだ。そして、理解しなくてはならないのは、...」 twitter.com/jcoplien/statu…

James Coplien @jcoplien

@cactaceae @ericevans0 ...there is a substantial process in turning an analysis perspective into implementation. And you must understand ...

2016-12-22 19:21:50

杉本啓 @sugimoto_kei

「...第一には、問題の方だ。DDDには、問題を理解し、それを切り分けて、設計、すなわちデリバリの単位にするための方策が含まれていないように、私には見える」 twitter.com/jcoplien/statu…

James Coplien @jcoplien

@cactaceae @ericevans0 ... the problem first. I see no measures in DDD to understand the problem and chunk it into design, units of delivery

2016-12-22 19:22:41

杉本啓 @sugimoto_kei

以上のコプリンさんの主張は分かり易い。でも、コプリンさんが言うような、問題を設計に変換する枠組みは、僕が知る限り、どのプロセス論でも弱いような気がする。MPDはそこをうまく扱ってたっけか。

杉本啓 @sugimoto_kei

@jcoplien @ericevans0 I am still in a muddle. A value for a user role may map to changes in mutiple design compoment, and vice versa. ...

杉本啓 @sugimoto_kei

@jcoplien @ericevans0 Is it in line with your saying mapping between an analysis and a design model is many-to-many? Or am I off track?