"Detailed Agenda for a Domain-Driven Design Design-Level Event Storming". That title is worth a lot of consultant scrabble points.
UserIsUnused 1630 days ago [-]
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 1630 days ago [-]
And the best things are things that sound important but that your competitors haven't offered, proving that your service is more comprehensive.
slashdotdash 1630 days ago [-]
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.
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 1629 days ago [-]
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 1629 days ago [-]
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 1629 days ago [-]
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 1629 days ago [-]
Yes that is exactly what I meant
1629 days ago [-]
adymitruk 1629 days ago [-]
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.
Rendered at 04:39:36 GMT+0000 (Coordinated Universal Time) with Vercel.
But now there are levels? Detailed Agendas are needed? Well, consultants have services to sell, gotta name things.
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
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.