In our continuing quest to break up our old monolith and create a more flexible and scalable architecture, we have realized that we need to look at some new tools and methods. One of the more promising approaches was Domain Driven Design, a term coined by Eric Evans in his Big Blue Book
Quite a few people in FINN has read (at least parts of) the Domain-Driven Design book, and we did some preliminary efforts to map our domains and look at our bounded contexts. We quickly realized that this was a very complex exercise, even with highly motivated tech and product people present. We figured we needed some help to get us on the right track. If you need help and information about DDD, why not get it straight from the horse’s mouth? So we got Eric Evans to visit us for a week at the end of February.
We needed to make the most of our time with Eric, so we set up a rather extensive agenda:
| Day | Subject | Attending |
|---|---|---|
| Monday | Strategic Domain Driven Design Course | FINNs CTO, our functional product directors, the members of our enterprise architecture group including our Chief Enterprise Architect, several key developers and a couple of our international friends from Schibsted Classified Media |
| Tuesday | Strategic Domain Driven Design Course cont’d | Same as Monday |
| Wednesday | Workshop: Ad concept and our miscellaneous vertical | Chief Enterprise architect, EA group, Functional Product Director, Product Owner, Lead Developers |
| Thursday | Workshop: Job vertical and company profile | Chief Enterprise architect, EA group, Functional Product Director, Product Owner, Lead Developers |
| Friday | Presentation for everyone in FINN.no, plus workshop: Communications | Chief Enterprise architect, EA group, Functional Product Director, Product Owner, Lead Developers |
The course on Monday and Tuesday was extremely helpful in getting everyone up to speed on the terms and method of strategic domain driven design.
The workshops the rest of the week focused on understanding the challenges involved in each area, and trying to map the bounded contexts of the existing systems.
Some lessons we learnt during the week.
- When you are trying to create a context map, start with a very concrete example of how the system works. Which components interacts with each other, what data is passed between them, exactly what does the input and output look like
- Use a huge whiteboard
- Plan to use at least a few hours on every session. Doing a context map for even a part of a system may take a lot longer than you think.
Then you can manage to turn something like this:
Into a nice map like this:
Our key findings on bounded contexts:
- Bounded contexts represent a higher order logical representation of a solution
- They may span several of FINN’s current “microservices”
- They are useful for understanding the high level architecture, and how teams and solutions depend on each other
The context map is a tool for discussions, and the boundaries and relationships are subjective.
Sample map focused on small subset of our system.
Example trying to map a larger part of our system.
Another thing we focused on was the concept of distilling the core. Figuring out which parts of your system that gives you a competitive advantage, and deserves extra attention. As part of this process it is also important to identify your supporting and generic domains. The tricky part is that it is really your business strategy that dictates what your core domain is.
So to sum things up: Having Eric Evans on-site for such a long time gave us invaluable insight into DDD, and how to apply it in our own business. Together the bounded context map, and our identified domains can help us drive development in the right direction. They are tools for discussion, not a framework that removes the need for highly competent developers.
Tags: architecture