At work, we are currently trying to iterate on event storming sessions.The aim is to stay at a very naive level first in order to model our domain model, and to iterate on it to add new features at the end of each sprint.

That means having a first draft of post-it on the wall for developers to work on for the first sprint, and in the mean time, having stakeholders and some devs working on the analysis of the next sprint.

This leads to handling two models, one that stays during the sprint and which should describe the model currently under development, and another that is evolving that should triggers the next sprint.

The issue I am facing is the storing of this knowledge. How do you handle such problems? Do you have any tools you might recommend ?

PS : is there any other communication canal , I might be using to discuss such things? hangout, gitter, slack?

User story workshop is nessesaryprocess before Event storming. Right?

+Alberto Brandolini, I have a philosophical question:
You describes the silos that exists in some companies...
And we use (Big picture) EventStorming in order to break them up to learn as much as possible.
But then, as we model the problem & solution space, we create new ones: Sub domains , generic , core, bounded context , ....

So what's the difference between the boundaries of the silos VS the one we create in our models ?

Could it be that the silos are the fossils of attempts at having an "agile" business ?
How can we, as DDD people, make sure that the solutions we bring do not become immutable fossils ?

I find it a fragile equilibrium to keep asking questions and challenging the models we have build to let them evolve.
While sometimes the business does not care anymore because they believe the problem to be solved or under control.
Or worse the team itself.

Post has attachment
Interesting discussion this morning, started by Thomas Perrain. https://twitter.com/tpierrain/status/956779596300668928 ...I guess some of you have similar experiences...

Had an interesting conversation a few days ago about Event or Command Sourcing. Recently I tryied a library to manage CQRS pattern (Brighter by Ian Cooper).
I like this library, it's flexible because let me the choice which eventstore to use, sql, mysql, eventstore, or anyone, but in this case you have to write your library and inject into brighter.
I don’t know if this blog is right for a similar discussion, but I'll curious to know if anyone did use Brighter, and what do you think about Event or Command Sourcing
(http://paramore.readthedocs.io/en/latest/EventSourcing.html)

EventStorming for data migration:

Here is the context, I'm working for a big insurance company in France. One of the topics is the data migration from the old legacy sytem to the new plateform. It inludes stuff like policies, claims, personal data, etc.
EventStorming on the first sight is not a right tool to explore what has to be done, or how it has to be done. One just take a sort of ETL, transforme some data from one system to another and you're done (in a simplistic way).
However I see an opportunity on how eventstorming might help here, but I'm not sure wheter it's a good idea or not. So some feedback would be welcomed :)

What I'm thinking about, is that data migration can be thought of as an accelerated lifecycle (in my case a policy), so different events can be triggered while the data is migrated like:
- TariffRecalculated (may be of interest of different contexts; Accounting, Policy managment, Communication, User access)
- InsurancePackChanged
- ClaimReported
- etc. etc.

I'm just experimenting but would be nice to have some feedback from the community.

Had fun in the last three days of educational workshop, playing with a different domain.

Instead of something we had a real expert in the room, we've chosen to run the workshop on something we had real customer experience: the Italian railways company.

I've chosen that, because everybody acknowledges that it's a complex domain. Yet we managed to model a lot of it. Or at least to have an emergent structure and vision of the next step.

It's been actually fun, because we ended up with quite a few proposal for improvement that turned out easy on top of an Event-Driven architecture.

Food for thoughts.

Alberto

Hey everybody,

I'm going to try out event storming within my company next week.
I really think my goal is to come to a common understanding and share the knowledge that is floating around in all the single heads.

In +Alberto Brandolini's book he states that this should not be used as a selling point for the strategy. So I wonder is it also a bad idea to set this as a goal for such a meeting?

Best Christian

Had an interesting conversation yesterday with +Paul Rayner about ...well almost everything! :-) However, one of the interesting bits was about strategies to wrap up the design artifact.

Looks like there are so many different ways to deal with that, and I am nowhere close to a definitive answer. So I'd like to hear your opinions/ideas about that.

Different context yesterday: more a product exploration than a business driven one.

The interesting bits were related to the fact that we were discovering designing not the perfect match for one specific organisation, but a more generic market fit.

Probably the most interesting one is that being right doesn't necessarily pay off: if the underlying problem is complex, but your users haven't realised it yet, they might be more inclined to buy something apparently simpler, matching their own mental model rather than something complex, that looks like "too much stuff I'll neve need". The real challenge became wrapping complexity with simplicity or presenting something with sophisticated internal machinery like a relatively trivial tool from the outside.

Other key point was: we have no guarantee that the customer's bottleneck is within scope. Our product might serve a support flow, and not the most critical one, or it might map with multiple bottlenecks in the company.

One of the approaches that seemed interesting was to try to solve at least one problem for a given category of users in a distinctive way, in order to hit the potential decision maker. Or consciously decide to focus primarily on some users, and limit ourselves to the basic homework in ancillary portions of the flow.

Alberto
Wait while more posts are being loaded