Arjan Noordhoek

@EisenbergEffect @allenholub Perhaps my talk about Outcome based interaction modelling will give you an answer. I argue that the actual work we need to do should always be reverse enginered from the outcome we want. Event modelling partly provides the means to achieve this. youtu.be/6kt2vpmRpTY?si…

Love this, Allen! So good. I wonder if you have thoughts on how individual user stories intersect with whole system coherence. Is that something that's part of the user story? Or is it something that comes in later as a requirement of the implementation? Or something else entirely? I don't believe "feature thinking" addresses this at all. In my experience, I've seen it do the opposite. However, when I'm working in terms user stories, and working towards a solution, I'm often thinking of that solution's coherence in terms of the larger whole. I'd definitely love to hear your thoughts on this.

IMO, the whole notion of a "feature" is misguided. They are unfocused, usually solving problems that don't exist (even when they also address problems that do). They suck up unnecessary time, add complexity, and increase the time from actual problem discovery to solution delivery. User stories are not features, and that's a good thing. They identify a narrowly focused problem that can be solved with a narrowly focused solution that gets into user/customer hands quickly. They are not amorphous "features" that may not fully solve any real problem. It's even worse when teams are tied to features and the teams are forcibly disbanded when the feature is "done." Self-selecting, flexible teams that restructure themselves around demand and skills are a good thing. Some outside entity tearing apart a team by force is not.

@adymitruk Fully agree Adam. System Thinking agrees with us. A system is not the sum of its parts, but the product of the interactions between its parts. We don't need to know the systems themselves but model only the results of their interactions, which are events.

A tragedy of the commons for data: The idea that your single normalized model is "least bad" for each piece of functionality in your system - one model cannot be ideal for each piece of functionality. So, even for trivial cases, organizing of coupling by #EventSourcing is superior. No one particular functionality is going to dominate a model that others are forced to use. Excessive coupling is almost immediately introduced to the simplest of CRUD systems where one tidy normalized model is forcing you to compromise on what can satisfy all your different needs in the system. It's making a trade-off in that a single projection into that canonical model that serves every screen or web page of your application is more efficient than managing multiple separate models per purpose. Without event sourcing, the risk is that you need to have faith that the any "old" data was in fact not relevant, relevant data is represented in a way that's usable by all functionality and you keep it flexible so as to not paint yourself into a corner when it comes to schema migrations. That's expensive and doesn't scale. The best canonical model is the raw events of what happened. That can serve any functionality of any web page or screen without this "tragedy of the commons" where one screen or piece of functionality takes focus of design for itself. The efficiency is the unencumbered data model you can now make for a particular piece of functionality - without needing full agreement from other functionality in the system.

Anyone interested in #eventdrivenarchitecture , #eventmodeling,#cqrs or loves their approach to deliver software projects to be challenged, watch my presentation "Supercharge @EventModeling by Making it Outcome-driven and Introducing Contexts" at 4pm US/Eastern time.

@datacubednz Thanks! My first design principle was "don't make me think". Visuals are essential in achieving this.

Anything that can visualise text or processes is a big win in my books #Neurodivergent #visualization

@stephane_jans @EventModeling Expect a lot more documentation and videos over the coming week

@arjanno @EventModeling Do you have any link where to find more info about this product?

Very proud to announce that Model My Code is now available for Beta testing and will be going live soon! A great new tool for modeling using elements from #eventmodeling, #eventstorming, #eventsourcing, #cqrs or any other event driven architecture. @EventModeling

@stephane_jans @EventModeling Modelmycode.com

@diegosasw @EventModeling @PlantUML @whimsical Hi Diego, Give ModelMycode a try. Its currently in Beta but will be going public soon. The Beta doesn't support scripting. But the full version will allow you to generate code in any language you want. Watch this space!