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

James Coplien @jcoplien

@hidenorigoto @cactaceae DDD seems to go from problem to solution, sans analysis, with techniques of physical system design for scalability.

James Coplien @jcoplien

@hidenorigoto @cactaceae (Thanks to Unmesh Joshi for input on the preceding Tweet). And I can find no small set of underlying principles.

r.ishibashi @cactaceae

.@jcoplien @hidenorigoto Thank you for the reply. I agree with @ericevans0's opinion. I felt that they were talking on different premises.

r.ishibashi @cactaceae

.@jcoplien Since I do not know SASD, I think I will study about it.

James Coplien @jcoplien

@cactaceae @hidenorigoto @ericevans0 So what is the underlying principle?

r.ishibashi @cactaceae

.@jcoplien @hidenorigoto @ericevans0 I understand that DDD's principle is "using just one model for analysis and design."

r.ishibashi @cactaceae

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

James Coplien @jcoplien

@cactaceae @hidenorigoto @ericevans0 An interesting starting point if so, and good insight by @cactaceae. Does that capture it, @ericevans0?

James Coplien @jcoplien

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

James Coplien @jcoplien

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

James Coplien @jcoplien

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

James Coplien @jcoplien

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

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

Eric Evans @ericevans0

@jcoplien @cactaceae @hidenorigoto that is a DDD principle. Doesn't define it, though. It isn't such a reductionist thing, I think

Mathias Verraes @mathiasverraes

.@ericevans0 @jcoplien @cactaceae @hidenorigoto To get to "analysis model == design model", you need to be comfortable entertaining ...

Mathias Verraes @mathiasverraes

@ericevans0 @jcoplien @cactaceae @hidenorigoto ...multiple models. Without optionality, you stick with your first model, and squeeze ...

Mathias Verraes @mathiasverraes

.@ericevans0 @jcoplien @cactaceae @hidenorigoto ...it into both analysis & design.

Mathias Verraes @mathiasverraes

@ericevans0 @jcoplien @cactaceae @hidenorigoto Postponing to choose a single model is smt I learned from DDD, and is a core principle IMO.

Mathias Verraes @mathiasverraes

@ericevans0 @jcoplien @cactaceae @hidenorigoto (Not just from DDD, I learned a lot by seeing @yreynhout's rigorous thinking style in action)

Mathias Verraes @mathiasverraes

.@ericevans0 @jcoplien @cactaceae @hidenorigoto Multiple models for a single problem + splitting a problem up with smaller boundaries.

James Coplien @jcoplien

@mathiasverraes @ericevans0 @cactaceae @hidenorigoto But DDD doesn't seem to work with the problem or with dividing it up—only the solution

James Coplien @jcoplien

@mathiasverraes @ericevans0 @cactaceae @hidenorigoto There is not any analysis in DDD AFAIK. Eric's book bolsters this perspective.

James Coplien @jcoplien

@ericevans0 @cactaceae @hidenorigoto Good. We have something to talk about. There's lots of background to this being a many-to-many mapping.

Thomas Schanko @tschanko1

@jcoplien @hidenorigoto @cactaceae can you elaborate on the last part of your statement? I wonder why ’… system design for scalability’

Thomas Schanko @tschanko1

@jcoplien @mathiasverraes @ericevans0 If I could come up with solutions only by dividing em up, without working on the problem, I’d be fine…