Domain-Driven Design at Lunar
At Lunar we are organized within Squads, each working independently on their mission. To achieve focus and efficiency we follow Domain-Driven principles by taking ownership and dividing it into different domains. A domain can be defined as a ‘sphere of knowledge, influence, or activity’ and in development, it often refers to its intended application. Domain-Driven Design is a term coined by Eric Evans, in his 2003 book of the same name, but it has since evolved in the hands of the developer community into much more. At Lunar it has become a critical part of our growth mindset.
What is Domain-Driven Design?
According to Martin Fowler, who we mentioned as an inspiration in this 2019 post on how we designed our architecture, Domain-Driven Design is an approach that centers software development on creating a domain model that offers a rich understanding of the processes. It is described as particularly well suited for complex domains, which admittedly running a FinTech operation can sometimes be.
“A model is a selectively simplified and consciously structured form of knowledge”
Ubiquitous Language
The idea of basing software systems on a model of a domain has long been around, but importantly, Evans developed a vocabulary to talk about it. He called this the ‘ubiquitous language’ and its purpose is to have all team members use it to connect all the activities of the team. On top of this identifying conceptual elements and embedding them directly in the code, imbues it with knowledge and a sense of its domain. Through this approach, you are able to evolve software models throughout their lifecycle. Antonio Theodorides, our Solution Architect at Lunar describes the most important aspect of Domain-Driven design as having a unified language between tech and the business. Being able to reason about problems using the same language to find solutions minimizes the gap in communications and supports alignment. It decreases cognitive load on the individual developer. But still, Domain-Driven Design is more than that:
Understanding and defining domains in Bounded Contexts
Domain-Driven Design is an understanding of one’s domain. Working in a domain and taking ownership of your software means you become the expert. At Lunar, we give developers code-ship-run ownership. This lets developers drive - and thrive and with it, we have adopted the saying:
“You build it, you run it.”
Theodorides describes it as being able to understand all the parts that make up your business and how they interact. To be effective, a model needs to be consistent and have no contradictions. At the same time, a model can only be understood in the right context.
“If sophisticated domain experts don’t understand the model, there is something wrong with the model.”
As a domain may grow larger, it becomes harder to build a single unified model. To combat this Domain-Driven Design divides larger systems into what is known as a Bounded Context, each with its own unified model.
Source: BoundedContext, Martin Fowler.
Bounded Contexts can have unrelated concepts inside but also share several. Different contexts may have completely different models of shared concepts. Various factors draw boundaries between these contexts. The boundaries are created and defined by the work of a specific team or squad.
How we practice Domain-Driven Design at Lunar
Some aspects of the approach may seem obvious, and many software developers already practice aspects of it intuitively. However, it is critical that developers use the business language consciously. Sharing the same vocabulary in naming classes in code as in strategic management, creates value for our business. Part of the job as a developer is working with non-coders to understand what you are meant to deliver - likewise, for any newcomer to the Squad, this might help them learn and catch up quicker. Theodorides puts it simply: It’s clarity. And that clarity brings much value; Better understanding, easier maintenance of code, better ways of integrating the code, and easier manners of changing the code. Domain-Driven Design is part of how we build things at Lunar, part of our architecture, and part of the onboarding process for developers. Each Squad should be domain-centric and understand the business reason behind every change.
“It’s part of our thinking here at Lunar.”
Event Storming - Part of our Strategy Design
Theodorides shared also how Domain-Driven Design becomes part of our business strategy through what is known as Event Storming (although he calls this ‘the world according to Antonio’ and emphasizes there are other methodologies for doing this). He explains that somewhere in the context of Domain-Driven Design making its stride in the early 2010s, an Italian IT-Consultant by the name of Alberto Brandolini invented Event Storming. Event Storming allows us to understand what is going on in the business end-to-end. It allows us to find our pain points. Say, for example, we onboard a new customer:
What triggers us onboarding the customer?
Where does that trigger happen?
What events does that trigger?
Who receives these events?
Commands or actions executed.
Actors execute these commands or actions.
“We get to learn about the business while simultaneously revealing this knowledge to the business itself. These shared insights and knowledge are extremely valuable.”
Big Picture Event Storming like this can be extensive, so we do not always want to do it. However, it gives us the ability to ask what problems we can solve, when we want, and which pain points we can do something about. Suddenly Domain-Driven Design becomes strategic. We can now figure out the steps we need to take to find a solution, what can and cannot be solved right now, and how to prioritize. Strategic Domain-Driven Design means what we need to do and which objectives we need to work on, while tactical Domain-Driven Design more becomes a question of how. Strategic Domain-Driven Design also splits domains into different subdomains:
Core domains - this is where we can differentiate ourselves as a business and part of what makes our organization special. This is where we need to build our own software for where there is no common solution. This should receive the highest priority and biggest effort.
Supporting subdomains - these support our core domains. They are necessary for the organization to succeed, but do not fall under the core domain category. They are not generic either as they require some level of specialization.
Generic subdomains - Here we can make use of what is already available, for example for regulatory reporting (although this still does spawn complex situations in our world from time to time). We can save a lot of resources by picking up off-the-shelf software for these subdomains.
An example of different kinds of subdomains at Lunar. Inspiration: Strategic DDD, Peter Holmstöm
User Obsession & Extreme Programming
Evans is also a big proponent of what is known as Extreme Programming (XP), an agile methodology to programming. He views Domain-Driven Design as a natural component of XP. It is an iterative process that features short development cycles and frequent releases and is intended to improve responsiveness to changing customer requirements. So while this may not yet be a formalized part of our approach, it fits perfectly well with Lunar’s efforts to be not just user-centric, but user obsessed. In the world of finance, things are constantly changing.
“The heart of software is its ability to solve domain-related problems for its user.”
By now you may be thinking to yourself that much of this is just one man’s opinion and while that very well may be, we have not just built our approach on his words alone. The Domain-Driven Design community has since 2003 grown large and spawned many additional learning materials which have further evolved the approach. Today DDD is truly in the hands of its practitioners and in true crowdsourcing fashion, all the quotes from Evans’ book shared in this blog post have each been highlighted by at least 1000+ Kindle readers.
Challenges
Being a scale-up is another contributor to things constantly changing and some of our Squads are still in their infancy. Domain-Driven Design certainly has a strong foundation here, but the level of implementation varies throughout the organization. Some Squads have got their language, allowing for clear conversations about their domain events and integration. Some still have to figure out what their domain is and what entities even are in theirs. In Domain-Driven Design the language and model should evolve alongside the team’s understanding of the domain, but with many new hires over the last couple of years, this can be a challenge for us as Domain-Driven Design encourages keeping the same domains with the same people.
“What you are trying to do is enriching your ability to work in these domains, by enriching your domain knowledge.”
When you expand rapidly, there is no getting around that people have got to learn and time needs to be set aside for it. There is effort required and it has to be maintained. This is important because, if it is not maintained, then it becomes inaccurate and then the domain expertise crumbles as nobody trusts it. There is a cost to this, but the benefit definitely outweighs the cost, says Theodorides.
Source: Public talk at 2022 AWS Financial Services Denmark by Kenneth Fiil (Head of Tech at Lunar), April 2022.
Domain-Driven Design fits our culture
Reinventing banking is not all that easy - but it is after all what Lunar is all about. We dabble in things here that have never been done before and because of the many unknowns this brings, we sometimes need to navigate domains where we are not necessarily the experts - at least not yet. Lunar is built on a foundation of technology and a growth mindset. Independence is key and we use Domain-Driven principles to achieve this goal and narrow down an area of interest to its core. This is why we delegate specific problems for each Squad to solve, allowing Squads in time, to become experts at what they do - even if they are first to do it. Traditionally, companies used to strive for total unification for the entire business. Domain-Driven Design instead recognizes that this is not feasible, nor cost-effective. The success of our Squads is apparent and even through organizational changes as we have grown from a small startup to a scale-up, this element of our business persists.
About Lunar
Lunar is a FinTech company founded in Aarhus, Denmark 2015 motivated by rethinking the banking experience. Unlike many other FinTechs Lunar operates as its own bank, with a license provided by the Danish Financial Supervisory Authority in August 2019. Lunar is a 100% digital bank, with a mission of giving you back control over your money by making managing your finances understandable, accessible, and easy for anyone. We now serve more than 500.000 customers across Denmark, Norway, and Sweden - and not just private banking customers, but businesses as well!
For more information visit our main website here.
Want to work for Lunar?
Lunar is full of talented people working on incredible things all the time. With more than 550 people across the Nordics - Aarhus, Copenhagen, Stockholm, and Oslo we are constantly evolving. This site is about just that: The technologies we utilize and create, our ways of working, our learnings, and company culture. If you are interested in joining us, check out our careers page!
