DDD Europe notes - Day 1
Matthias Noback
Eric Evans: Keynote (“Language in Context”)
Starting out with the basics (words have meaning within a context; when we make the boundary of this context explicit we end up with a bounded context), Eric discussed two main topics: the Big Ball of Mud, and bounded contexts in the context (no pun intended) of microservices.
Legacy applications are always framed in a negative way, as if it’s something to get away from. Personally, I’ve come to enjoy them a lot. However, there will always be the urge to work around legacy code. The Bubble Context (PDF) can be a great way of creating a new model that works well next to the already existing models. To keep a safe buffer between the new and the old model, you could build an Anti-Corruption Layer (ACL). A fun thing Eric mentioned is that the buffer works in two directions. The ACL also allows the old model to keep functioning without being disturbed by all the new things that are going on in the Bubble Context.
Given that a bounded context may or may not align with an actual subdomain, it may very well be that a legacy context is actually a Big Ball of Mud, with unified models, and simply just a lot of domain knowledge written between the many spaghetti lines that are in there. However, even though it is a mess, and it’s getting harder to work with it every day, it may still be what you could call a “Mature Productive Context”. The question is: is it still aligned with business views? If it is, we could improve at least maintainability and the cost of change by performing local refactorings. If it isn’t, it’ll be very hard to change anything. If the basic assumptions of the model change, rework will be very costly.
As a matter of fact, for a project I’m currently working on, we’re looking into a module (or context), which requires some heavy refactoring, because it has become technically very hard to work with it. However, the business is still quite happy about it, and it’s quite central to its processes.
An important Domain-Driven approach which can be used in the area of legacy code is where you analyze the different subdomains, and find out which ones are generic, and which ones are “core” to the business. As an example, in the aforementioned project there are actually two candidates for context-level improvements. One is related to Sales (which is the heart of this financial application), and one is related to Addressbook records (which is very much supportive to the Sales part). One could say it’s even generic, in the sense that an off the shelf solution might be preferable. We wouldn’t want to spend a lot of design or development effort there either.
Eric mentioned the term “Quaint Context” as a suitable name for a context that one would consider “legacy”. It uses outdated technology probably, and has become hard to maintain. It won’t be possible to make big changes there (as mentioned, because these basic assumptions can’t easily be changed), so another good name could be “Patch-by-Patch Context”.
With a microservice architecture, another option to deal with legacy contexts becomes what Eric calls the “Exposed Legacy Asset” (yet another nice term!). This will be a legacy application which starts to adapt to the microservices environment by producing messages that will be useful for actual microservices in that environment. For instance, database triggers could be used to produce events. The external events themselves don’t have to be as low-level as the internal events that caused them.
Eric touches on several other interesting aspects of microservice architecture, but I wanted to briefly mention some other relevant ideas here. Eric looked back at 15 years of Domain-Driven Design and proposed that by now we maybe need a definition of DDD itself. He doesn’t want DDD to be just a club, but asks for intellectual honesty. If you try to apply DDD and somehow it fails, you should share this story. If you’re skeptical about some aspect of DDD, talk about it. I like how it boils down to focusing on the core domain, exploring models together, and speaking a ubiquitous language in an explicitly bounded context. Nice!
Rebecca Wirfs-Brock: Growing Your Design Heuristics Toolkit
This one was a workshop with limited access, so I was lucky I could attend it. Rebecca had spoken in a previous edition of the conference about heuristics, which triggered my interest in the idea. The workshop was about the process behind it. It had some interesting pointers, like a PDF about the concept and a book by Billy Vaughn Koen: Discussion of the Method. Definitely things to check out!
Rebecca defined “heuristic” as a practical method, a rule of thumb. Heuristics are things you collect over time, when you find out what works best in a certain situation. They may be hints about how to solve a design problem, or how to find out what to do next, or how you should relate to something.
An example of a difficult situation in software development is when you encounter “smelly” code. Something’s wrong. It needs fixing, but: do you do it now? Never? Only in certain cases? One could say: if you see a problem, fix it. Another would say: if it isn’t broken, don’t fix it. Or maybe: never fix it. Don’t touch anything at all, because it might break.
We all have some intuitive approach in this matter, and I find it very interesting how:
- This approach changes over time.
- Many people will have many different approaches.
Rebecca suggested keeping a journal, describing and reflecting on how you actually tackle design issues.
We practiced collecting heuristics according to a somewhat fixed recipe. Here’s an example:
Question: Should I fix code smells whenever I encounter them? Heuristic: Only fix them when you’re working on the code. Example: If you’re just reading the code, don’t improve it just yet. If you dive in and make changes because of a new feature was requested, or a bug had to be fixed, add a test and fix the smell.
You can collect these based on your own work, and when talking to someone else you want to learn from, you can start collecting many more. When finding out which heuristics other people use, it helps to challenge them. Ask questions, find out the exceptions, the many other subtle things that should be taken into account, etc.
I found the workshop very interesting and was happy to learn more about this useful concept of a “heuristic”.I feel that writing about technology has always been about exposing my own heuristics, or rules of thumb, and by sharing, maybe I can help others too. I think there’s a fundemental issue with writing though: it may only “click” with the reader when their experience somewhat overlaps with the experience the writer had. You have to recognize at least part of what’s in the book/article, before you can relate to it, or can “accept” it as something useful.