Many people believe there should be one, and only one, way to model software. I think differently, I like to mix different techniques.
\nFor instance, I believe there’s a strong synergy between C4 Model, Context Maps, and EventStorming. They all allow us to look at the system from a different angle and act as simulations, providing different feedback on whether our model will fly.
\nLook below for the diagram I prepared for my upcoming workshop.
\nIt’s a C4 diagram showing containers in a hospitality system (so-called Property Management, where property means hotel).
\nA container gives quick feedback on how many pieces I’ll potentially need to manage and deploy, and it also shows me boundaries.
\nContext Maps help in understanding how they relate to each other, which module or team has bigger leverage, and can force more on others. It can also show me the information flow and simulate which module will expose the API.
\nI can then take some business process and have a look at how the message flow will look. This can happen as an early simulation or after EventStorming sessions.
\nThen C4 allow me to also look inside the container, show components if I need to understand more details. I can group containers if my bounded context has more of them.
\nHow to start with it? Let me show you an example.
\nThe starting point could be understanding the system’s overall view; integrations with external systems usually introduce the most complexity. C4 System Diagram works well for that.
\nWe see actors representing our system users and interactions with external systems. We can decide what integration is out of scope for now, and may come as the second step, but not for now. We can also show the current state as is, then in the second diagram show our vision of what we want it to be. Be creative, this is not a relational database, we don’t need to normalise it.
\nThen we may decide to dive into what we need to build to facilitate that, make a bet based on our current knowledge, zoom in and check the C4 Container view.
\nWe can even use colours, e.g., upstream as green and downstream as red. This can already give us feedback, e.g., that Cashiering is an important module for financial processing and that it is downstream of multiple modules. Maybe we can change it and redefine boundaries, or maybe live with it, but take some corrective actions.
\nWe can also put more data and use a specific example of a process and have a look at the specific process, as shown in the original diagram:
\nThis can also pinpoint some issues, e.g., a generic module, which is more likely to expose commands (see more on why in my article on Passive-Aggressive Events). We can see if we have all the needed ACLs defined, or which module acts as a coordinator.
\nOf course, keeping it all on the same diagram is not perfect; it’d be great if we had a tool that would enable zoom-in/zoom-out, link and enable/disable some of the details and notation. Then we can even better play with what we have. Maybe I should vibe such?
\nNevertheless, I encourage you to try different techniques, experiment, and combine them. For instance, Example Mapping would, imho, play great here as an extension. I know that some use Wardley Maps or Domain Storytelling.
\nStart small, use existing techniques and tools, and try to see how you could benefit from mixing them. Show it to your friends and try to collaborate and have fun together.
\nI even learned from Richard Gross that this has an even name: Model Storming. So, crunching your design with different modelling techniques and coming up with some useful variations.
\nI have even more mashups like that. Tell me if you’d like me to expand on it or this part in the follow-up articles!
\nAlso, if you did such experiments, please share them with me and others. Happy to see what you came up with.
\nCheers!
\nOskar
\np.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.
","excerpt":"Many people believe there should be one, and only one, way to model software. I think differently, I like to mix different techniques. For…","fields":{"slug":"/on-mashing-up-modelling-techniques/","prefix":"2026-05-18","langKey":"pl"},"frontmatter":{"title":"On mashing up modelling techniques for fun and profit","author":"oskar dudycz","category":"Software Architecture","disqusId":null,"useDefaultLangCanonical":true,"cover":{"childImageSharp":{"resize":{"src":"/static/5ed088d85a6e4f737c6da5b2c7eaabca/4fe8c/2026-05-18-cover.jpg"}}}}},"authornote":{"id":"295c4649-a20b-5147-9ca5-5cb77fbcfe66","html":"Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.
\nSome time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.
\nMany people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.
\nMany seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?
\nThe end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.
\nI believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.
\nAfter I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?
\nPeople usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).
\nThe truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.
\nTherefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.
\nPolish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.
\nCheers!
\nOskar
"},"site":{"siteMetadata":{"facebook":{"appId":""}}}},"pageContext":{"slug":"/on-mashing-up-modelling-techniques/","lang":"pl","langKey":"pl","prev":{"id":"1dcd1d37-05f5-5f2d-8858-247c94faa3ad","fields":{"slug":"/should_we_trust_domain_experts/","prefix":"2026-05-11","source":"posts","langKey":"pl"},"frontmatter":{"title":"Don't overestimate domain expertise","category":"Software Architecture"}},"source":"posts"}}, "staticQueryHashes": ["2742854296"]}