
Detailed Agenda for a DDD Design-Level Event Storming - philou
http://philippe.bourgau.net/detailed-agenda-for-a-ddd-design-level-event-storming-part-1/
======
remon
"Detailed Agenda for a Domain-Driven Design Design-Level Event Storming". That
title is worth a lot of consultant scrabble points.

~~~
UserIsUnused
Event Storming as a concept is nice. (i.e. Before building a system, talk with
stake holders about relevant "business logic" events happens on the system) It
helps with building a common language, and understanding about what's
important to the product.

But now there are levels? Detailed Agendas are needed? Well, consultants have
services to sell, gotta name things.

~~~
taneq
And the best things are things that sound important but that your competitors
haven't offered, proving that your service is more comprehensive.

------
slashdotdash
Alberto Brandolini’s “Introducing EventStorming” [1] book is worth reading,
even in its incomplete state, to understand the approach from its author.

There aren’t too many concepts to understand, it almost feels too simple to be
of any value. But in all of the sessions I’ve been involved with participants
have come away with a better understanding of the domain and often a useful
model to begin working from.

[1]
[https://leanpub.com/introducing_eventstorming](https://leanpub.com/introducing_eventstorming)

------
dwags
We are currently in the process of reorganizing our teams to use DDD &
Gherkin. Any tips? There is a lot of churn currently and I have not yet seen
any real benefit to it. Context -- I'm full-stack, our team has recently grown
to a point where we needed more organization than just throwing a
frontend/backend pair at a story/task. Our team is distributed across the
country as well.

------
codeulike
I read the DDD book by Evans some time ago. There's a bit where he was
essentially saying "Even when you're really good at it, Domain modelling is
still very hard to get right". So that left me thinking: Well, why bother
then? Why subscribe to this methodology is its so hard to properly realise the
benefits?

~~~
lucisferre
I'm really trying to understand what you are saying here. It reads like you
are saying that because something is hard it is not worth the effort. I mean
would you not expect the benefits to outweigh that effort, or at least assume
that this is what the author believes to be true?

~~~
james_s_tayler
I think there is a valid point to be made that as the difficulty of something
goes up the number of people capable of producing good results with it goes
down. That leaves all the other people who try to use and wind up producing
poor results. If the difficulty is such that there is a greater chance you
will produce a poor result with it than a good one then it might not be worth
taking such a gamble but rather sticking to a simpler methodology capable of
producing good results a greater portion of the time even though the best
result it can possibly produce is less good than that of DDD.

I really think there is an argument to be made for that. It's not that people
are stupid, it's just that things are hard. Doing simpler things helps
communication scale as it's easier to get everyone on the same page and
engineering failures are almost always the result of communication failures
across the engineering org.

~~~
codeulike
Yes that is exactly what I meant

------
adymitruk
The readers should also familiarize themselves with Event Modeling which goes
with or without DDD. In fact, it can describe traditional systems while
keeping the event-centric mindset.

