PayFit on the Domain-Driven Design Journey

Planting the Seed

The Domain-Driven Design (DDD) journey at PayFit started in 2021, more than 2 years ago with a book club, originally composed of engineers (mostly individual contributors and a few managers). We met bi-weekly to learn and share what DDD is about and how the paradigm and the concepts can be applied in relation to our daily challenges, while also looking for possibilities to apply what we learned.

Word of the book club began to spread, and the group started to grow partially organically and partially by inviting colleagues so that it became more diverse by having product, design and domain experts as members. This allowed us to create and improve the common understanding of some domains and their boundaries, to define and refine domains and shared terms for Time Planning or for Payments, for example.

The first seeds had been planted. Now it was time to carefully and patiently nurture them…

Bringing in the First Crop

The benefits of being patient soon became clear. Several features and refactoring initiatives began with collaborative modelling sessions, like Event Storming as the first step. It brought a lot of things to the table (including processes we have never thought about)! or It was super useful to see the complexity and the different understandings of the team. are just some of the comments received after these workshops.

As a side effect of our domain discovery workshops, evolving the understanding of our business domains brought improvement opportunities regarding our organization structure. This wasn’t just a theoretical problem, there were improvement opportunities to act on :

• How teams were interacting
• High need for coordination and collaboration
• Slow product development
• Inefficient work

Additionally, PayFit was growing rapidly. The costs of dependencies and slow product development work were equally increasing and becoming untenable. The organization could see this and wanted to give teams more autonomy and empowerment and reduce dependencies. it became that a new way was necessary to organize teams :

aligned to the business outcomes and the domain over technological layers, and also leveraging platformization.

But, this had to be done carefully. One crucial example was handling payroll data. This involves working with highly sensitive data. While it was time to find a way to empower teams we had to also ensure a holistic data governance, consistency and decentralized decision making.

Senior leadership gave the go-ahead for a series of domain discovery and modeling workshops to map out the company domains and rethink the organizational structure. Damian took the responsibility to get all this organized across the whole organization, and I (Christina) became the facilitator of the workshops, both of us being aware of the potential impact this initiative will have.

Planting the Whole Field

One of the first workshops I ran was a deep-dive into our core domain, Payroll. As I spoke to different groups, everything seemed coupled to Payroll so this seemed like the essential starting point. The purpose of the workshop was to gain alignment on the domain model, like what domain concepts are involved, how they relate, and where do people see the boundaries.

Shortly before the first workshop, I started together with Jean de Barochez (embedded architect in the Payroll Team) an unusual kind of domain discovery. A “knowledge crunching” started in writing instead of stickies or diagrams about Pay Period, a core term used quite fuzzily.
We started the asynchronous exchange on the documentation platform by asking everyone related to add their definition and known usages for the term. A kind of RFC (Request For Comments) but with the goal to collect knowledge instead of suggesting one decision.
After some time, the gaps and the misunderstandings became transparent. By having all the needs and interpretations in one place it was quite easy to realize that people were actually talking about different concepts. Pay period is the widely used, customer focused term but is missing the concept of the payroll lifecycle: the period of time a payroll is referring to. Usually, this is one month but some countries allow shorter periods too, for example one week. This need was identified earlier as valuable but it has needed a name and a meaning to be able to implement it. Now it has gotten a name and a very clear description used as the target vision at the deep-dive workshop.

The name Payroll Period is only slightly different from Pay Period as a name but it leads to a completely different implementation. We continued to build up a mental model around this name, using the MindMap in Figure 1, and after a short time we ended up with a domain model ready to be implemented.

During the 2-days workshop, a diverse, cross-functional group, including the product manager, design expert and the engineers, stormed, explored, and iterated on the Payroll Period domain model. We ran through the most important use cases to build a deeper shared understanding of the current functionality and proposed future changes.
This helped us to explore the optimal architecture. The artefacts from the workshops were :

• A Bounded Context Canvas documenting what belongs to Payroll Registry, what doesn’t, it’s main responsibilities, and how it communicates with others
• One draft of a canvas describing a new context called Payslips, which was considered as an internal implementation detail of Payroll Registry until that moment (DDD started to do its magic: we started to divide and conquer based on business needs, not on technological heuristics)
• Four Domain Message Flow diagrams describing the main use cases
• The future design of Payroll Registry and its relationship with the Payroll Period, documented as the Payroll Vision to be shared with everyone impacted (and interested). An RFC to share it throughout the engineering organization
• The next step to make it happen - a fast experimentation to validate the concept based on real production usage compared to planning and assuming things which was the default.
• Key challenges, like rolling out a completely new architecture and design by migrating slowly from the old one. We knew the company couldn’t afford to sit still while we rewrote the whole system so had to be realistic.

I want to really emphasize that all of this happened because we focused on clarifying a single domain term. Naming is hard and it is a key driver for all kinds of decisions, both business and technological.

After this first deep-dive in the heart of the product, a series of big picture discovery workshops were started for all Payroll-related domains and other areas that needed to be tackled by a successful product, like the self-serve experience.
The purpose of the workshops was to :

• Explore the four highest priority business objectives
• Identifying the relevant domains
• Define a shared language
• Explore team organization options
• Improve team autonomy to make decisions and work with fewer dependencies

Our colleagues from the different teams organised the workshops and made sure that they invited everyone with domain knowledge; I have designed and facilitated them. Participants covered the whole spectrum of employees, from sales to customer support, product, design and engineering experts, from multiple countries. Each workshop followed a similar structure :

• describe the current situation (each topic owner added the most important resources to the miro board before the workshop so that everyone could have read up, if necessary)
• start a conversation about the daily work, about the problems and the needs and put all this on the board
• collect terms and their meanings so that the gaps and the misunderstandings became transparent.
• EventStorming on the most common use cases and identifying domain boundaries (this was the whole 2nd half of each workshop)

One piece of advice I would like to offer anyone interested in running these types of workshops is to focus on knowledge sharing, and not just on the outputs. In our workshops, people got to hear about business needs and business processes directly from people involved, rather than hearing from a proxy.

People loved getting this deeper understanding.

While the agenda was the same for each workshop, the outcomes and next steps were completely different.
For example, two topics got merged because we discovered they were both related to addressing the same needs. Another example was when a workshop uncovered three “black holes” (areas we didn’t realize existed) which required three additional workshops.
The third topic did actually follow the initial plan to collect all the information, agree on the boundaries and pivotal events and start filling the Bounded Context Canvas. (This canvas will soon become the standard documentation for teams to talk about the domains they handle and also to start the collaboration with other, “neighbouring” contexts).
The fourth topic was huge, including the whole self-serve experience and all the related domains. This initiative was already on-going so that even before the discovery workshops were done it was possible to create and use the first Message Flow diagrams to challenge the boundaries and plan the iterative implementation.

There is so much more we would love to share about our journey at PayFit, but for now, here are some of the quotes from some of our team :

• We came to a satisfactory common definition of the Declaration domain at the Company level, and this let us make the right arbitrations to create a hybrid team with a diverse product/tech skill set, including a whole team of Product Builders.
• This is a testimony to the efficient methodology behind DDD and we are hopeful other significant results will come out of the discussions on other domains - Ghita Benotmane, Product France Director after two rounds of Big Picture Discovery Workshops, expressed during a team review
• I was surprised by the high level of engagement and collaboration at a meeting where the attendees were supposed to take the ownership over more work! - Francois-Xavier Paradis, Product Manager of Declarations after a hand-over meeting necessary to move functionality to the right domain-owners.
• Before the “computes” and payslip generation were the same, but now they are different and it has an impact on the UX. It’s a great example of how DDD helps us to improve and to decouple the scope of teams because now we have two different concepts for what used to be one “big thing”, and the payroll team has full autonomy to improve the UX related to payslip previews. - Clément Ricateau-Pasquino, Engineer and DDD practitioner working hard on stability and reliability improvements.

All this started 2 years ago with a book club.

Now PayFit is well on the journey, each day benefiting from the new way to understand needs, learned thanks to the Domain-driven paradigm. Leaving the usual comfort zones “Engineers talk about tech, product managers talk about product (and don’t want to know about tech) and nobody talks with the designers” is hard - the hardest part for everyone.
But getting used to thinking like this is the first step in finally closing the gap between the vision of a product manager and the solution implemented by the engineers.

Note from the authors : This text also feature in the book Architecture Modernization, chapter Learning and upskilling, by Nick Tune.