Domain-Driven Design (DDD) incorporated in a payment platform intended to allow global expansion

Introduction

Hello, my name is Go Wada, and I am responsible for the payment platform backend in the Shared Service Development Group. The project I am in charge of has been engaged in Scrum-based development using domain-driven design since our team developed the platform. This article uses the experience gained there to give an example of how this was implemented efficiently by a team.

What is "Domain-driven Design (DDD)?"

DDD is a method of developing software. It is intended to improve software values and problem-solving ability through modeling. For example, we utilize use-case and domain-modeling diagrams to represent models. Moreover, we try to use ubiquitous language or in other words, to allow developers, business members, and everyone involved to engage in a dialog using the same terms. Of course, one of our goals on the technical side is to improve the quality of our code. For example, rather than creating tangled spaghetti code, we put together loosely coupled highly cohesive implementations that are resistant to change. We focus on preserving consolidation, "Tell, don't ask!" style checks, and on being aware of SOLID.

*Addendum: "Domain" refers to the domain in which problems are to be addressed with software.

Issues for our team

Our team faced the following challenges in introducing domain-driven design.

• We chose DDD as a software design approach but it was more difficult than we had anticipated

• We learned individually so there were differences in our understanding

• The team was made up of people working together for the first time

Conversely, the team's policies and vision for the future are:

• To move ahead with efficient development
• To improve the maintainability of our systems and increase the speed of function development in future development work (or alternatively, to avoid slowing down once we are on track)
• Development is an opportunity for learning, so we would like to learn well as a team.

Group readings of proposals to address these issues

There are a range of ways to address these issues, and we decided to confront them by holding group reading sessions where we read books on domain-driven design. Our aims were to:

• Read about DDD as a team effort
• Make learning efficient, with a deeper reach (improving our skills as a team)
• Gain a common awareness and an understanding of each other through the casual conversations that occur at the group readings
• Align awareness of assumptions to reduce pull-request conversations
• Create a sense of team unity through discussions and casual conversations at group reading sessions

How we implemented group reading sessions

We used the following methods to implement group reading sessions:

1. We engaged in circular group readings of "Domain-Driven Design: A Modeling/Implementation Guide," by Koichiro Matsuoka

   https://little-hands.booth.pm/items/1835632

2. Everyone participated with the consent of all product members

3. Once a week, people assigned responsibility for each chapter are nominated to make a 30-minute presentation

   • They read their assigned chapter in advance, and create documents summarizing the important points

   • The presentations take about 15 minutes, with discussions lasting approximately the same time

Discussions at group readings

Although this is written from memory, conversations generally went as follows.

• Consistency-wise it would be better if we only ever allow correct instances to exist
• This is how domain services should be (don't make careless mistakes, better to restrict responsibilities)
• Better to use specification objects as a single method of validation
• How to view value objects (it might be safer to use elements comprising aggregate routes as VOs)
• Aren't the presentation and application layers mixed up? The naming got confused
• What should we do about the architecture (layered architecture, onion architecture, clean architecture, etc.)

Starting modeling

Although we couldn't wait to get started on coding, modeling is also important, and so we periodically took time within each sprint to go over it with everyone. Team members who are familiar with payment-related systems and operations were appointed as domain experts. Since the payment system itself is implemented within the system, it is more important to be familiar with the details of the system than with the business. The content implemented was roughly as follows.

1. Using miro, we used sticky notes to brainstorm concepts related to payment.
   Results of brainstorming

2. We organized the resulting concepts and discussed the relevant points as follows.

   • What payment-related actions are required by a payment platform?
   • What chronological order should these actions take?
   • Which are the aggregation routes?
   • How can we organize the concepts to fit effectively?
   • How are other similar systems organized?
     Image diagram of conceptual organization *We reevaluated this diagram every time we felt something was not right, as well as after brainstorming.
     Image diagram of brainstorming progress *Deformed image of work progress.

3. We created domain-model and use-case diagrams of the results of our discussions.
   Domain model
   Domain model excerpt

Of course, the model was not the end of the process, as we made numerous improvements.
For example, initially we intended to make the payment aggregation payment card entity a dedicated aggregation.
This was because we had an image of the payment card holding the payment company information, and we had decided that since this is an external system it would be easier to handle aggregation separately.
However, any given payment generates information that this key value was used to deal with the payment company, which cannot be separated from payment.
We reviewed our assessments so that they were strongly consistent, and decided to include them in a single aggregation.

Use case diagram *Although we created use-case diagrams, we discarded them as their content overlapped with that of other documents.

4. We created a glossary.
   During brainstorming and model creation, we noticed that each member used different terms to explain the same thing.
   That prompted us to create a glossary of appropriate terms that the team could agree on from the multiple terms that we were using. (We defined both Japanese and English terms.)
   To ensure that we use defined terms, members gently point out (jokingly) each other's mistakes when they use incorrect terminology.
   Take the example of a system in which a payment platform is to be installed, which requires contracts to be made for each so-called order unit before payment. We decided to call those contracts "Payment directives." This is because we thought that "contract" could be construed as having a range of meanings.
   Moreover, this glossary is intended to avoid confusion with terms used in other systems and products (outside the defined context).
   Glossary image

Lessons and benefits from carrying out model and group reading sessions

Group reading session

Held in parallel with our regular work, the group reading sessions provided us with the following lessons and benefits.

• The amount learned and the precision of our products increases as we can apply the knowledge from these sessions immediately
• It is suited to Agile development because we soon have an opportunity to apply this knowledge
• The ability to have a common understanding improves quality because pull requests are viewed from different perspectives
• You develop an interest that encourages you to read other related material (you develop momentum to learn)
• You can learn systematically, not just areas related to your own work, making your learning more versatile
• You can be more active in these group reading sessions than in sessions on unrelated topics
• Active conversations create an even better team atmosphere that helps to counter the isolation of remote working
  *These sessions were very active, making timekeepers a necessity.

Modeling

Taking time to conduct modeling on a regular basis provided us with the following lessons and benefits.

• Although we tend to focus on implementation, we have gotten into the habit of basing our thinking on the model
• Looking at things on a model level gives us a feeling for the overall product
• When we are about to lose our way during implementation, we can go back to the model for clarification

Outlook for the future

Although we have implemented the practices described above, at the time of writing we have yet to put them into operation.
At our current stage in development, we appear to be successful.
However, we hope to assess whether these activities had merit and what their challenges were based on feedback we receive from actually using them in practice. Additionally, to a large extent, domain-driven design itself is more of a path for thinking than a deterministic methodology.
We hope to acquire more knowledge, including the information acquired through our operations.

Summary of what was learned through the practices described here

At the group reading sessions, which were held in parallel with our normal operations, we learned that:

• It is possible to achieve input and output of learning, reflect learning in our products and the growth of our team's members all at the same time
• Work-based and experiential learning are linked
• All related personnel can be actively involved, and conversation used to create a sense of unity.

The habits we have acquired through modeling showed us:

• Although we tend to focus on implementation, we learn to base our thinking on the model
• Looking at things on a model level gives us a feeling for the overall product, making implementation less localized
• When we are about to lose our way during implementation, we can go back to the model for clarification, making it more difficult to become confused