A Different Take on Context Mapping at DDDEurope 2020
Watch me explore how we can improve mapping in DDD at DDDEurope 2020. Can we make space more meaningful in a typical Context Map? How can we visualize our intended changes? Is there a way to markup maps with forces on our model outside of code? And what impact can we expect from things not part of our map?
But we were young and foolish.
So by the time our understanding of the domain had grown, we had to modify a whole bunch of models that were in production.
This isn’t a bad thing but it can be a tough job if you haven’t done it before.
Because how do you change a projection without causing problems or downtime for your customers? And how do you know it works as intended?
Back then we tested a lot on a staging environment, we timed well and we crossed our fingers #startuplifeyolo.
But please, save your hair and don’t use that approach. Use feature toggles instead to evolve your models with ease.
As a professional trainer I get to deal with a lot of interesting dynamics when it comes to education and practice in organizations.
By far the weirdest behavior is the urge to postpone a training if someone cannot join.
How fast you can type is usually not a constraint on software design work. However, having to write the same boilerplate code again, and again, and
again can be quite a drag. Over the years I’ve started to use PHPStorm – my IDE of choice – better and better. One of its features is “Live
Templates”. These can be used to generate small sections of code in particular types of contexts, like files, class bodies, method or function bodies.
Communication is difficult and that is why misunderstandings happen. Some people feel that they have “communicated it” when they have “told someone”.
In my opinion that is too easy. Making sure someone understands your point of view is for a large part the responsibility of the person sending a
message. And that responsibility includes seeking confirmation if what was communicated is also understood.
A list of random tips for Event Storming facilitators
Learning to facilitate an Event Storming workshop requires trial & error. Effective and useful Event Storming workshops have a mix of
people with questions and answers. As such aspiring facilitators need to learn facilitation with a mixed group of participants, most of whom might not
be so patient with the learning cycle of the facilitator to be. This list of training wheels will help you get started and prevents common pitfalls.
How often have you found yourself sifting through a configuration file to look up some settings? That can be quite a daunting task on some projects, right? I just picked three large projects I worked on. They contained 38, 121 and 68 parameters respectively.
Sure, you’ve heard it before: naming is hard.
I’m also confident that this isn’t the first time that someone tells you to drop technical patterns from your naming strategies.
But have you ever tried it? And if you did; have you applied yourself to take it beyond the obvious?