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:
-
We engaged in circular group readings of "Domain-Driven Design: A Modeling/Implementation Guide," by Koichiro Matsuoka
-
Everyone participated with the consent of all product members
-
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.
-
Using miro, we used sticky notes to brainstorm concepts related to payment.
Results of brainstorming -
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.
-
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.
- 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
関連記事 | Related Posts
Trying Out Modeling with EventStorming
EventStormingでモデリングしてみた
KINTO Global Innovation Days (Winning Team Interview)
Remote Mob Programming: How a Team of New Hires Achieved Success Developing a New System Within a Year
The Best Practices Found by Backend Engineers While Developing Multiple Flutter Applications at Once
Leadership at KTC
We are hiring!
【フロントエンドエンジニア(オウンドメディア)】DX開発G/東京
DX開発グループについてモビリティにかかわる様々なDXサービス・プロダクトの企画推進とシステム開発・クリエイティブ制作を行っています。
【PdM】my route開発G/東京
my route開発グループについてmy route開発グループは、my routeに関わる開発・運用に取り組んでいます。my routeの概要 my routeは、移動需要を創出するために「魅力ある地域情報の発信」、「最適な移動手段の提案」、「交通機関や施設利用のスムーズな予約・決済」をワンストップで提供する、スマートフォン向けマルチモーダルモビリティサービスです。