How We Align Product Ideas with Software
Our primary motivation is designing functional, well-detailed, and scalable systems throughout the journey. All of the wallet apps directly touch user experience. The system’s domain is making a wallet application that users put their money and smoothly charge them. Interaction with money makes an intangible behavior on the wallet application. Due to intangibility, developers and QA Engineers must ensure the business rules regardless of technical excuses such as databases and network topology.
Business rules are projections before the implementation
When we start planning meets with product managers(of course, the agile-based methodology is crucial for the communication over roles), we will take all scenarios about the story. Let’s demonstrate the account creation scenario;
Developer(me): Which inputs do we need for account creation?
Product expert: just a valid gsm number
Developer(me): How do you make a gsm number validation?
Lead developer: you can use the external-sms-api to send an OTP token also to validate the code.
Developer (me): do users have restrictions about the account creation?
Product expert: yes. One user has only one gsm number.
Developer (me): so, we make the unique relationship between the account and gsm number.
Lead developer: currently, we use a gsm number for a validation process. We may use other options to make validation before the account creation.
Developer (me): so, I rename the gsm number with “AccountCredential” name. My business rule is, “I have an account credential for validation. Whether the validation process will be a success, the account creation would be guaranteed”.
Before all technical requirements, the DDD principle tells that each implementation of the working software corresponds to a business requirement. In this scenario, we defined a model for the “Account Creation” requirement.
The current objective is to implement the business feature into the code. Once we created the “Account” model, we will add attributes if the necessary business feature has refined. We defined mathematics for the business and technical layer. The Domain-Driven Design steps in at this point.
Make a Ubiquitous Language
Mostly technical roles do not interest in the business domain; also, product roles do not focus on implementation details. We have to align both of these genius friends.
Importance of feedback mechanism
First of all, we start to crunching ideas on the table. We disallowed the roles. Anyone shares their opinion about the feature. This communication mechanism brings to an ownership attitude over the tribe. When the owner has fully maintained, strong feedbacks has come along. We need a bidirectional way of communication. Because legacy methods such as waterfall have one-way communication. The business gathers ideas and extracts the model for implementation. Techie roles make programs and tests.
We use feedbacks. Feedback is the most critical action while crunching ideas. Feedbacks are just like pre-rendered images. Everybody has the idea’s inner mechanics, but they don’t exactly know at the end of the day. The feedback mechanism allows both business and technical roles to demystify their mental model and either role to gain proactive habits. Business knows how the developers and QA engineers act the idea. Also, feedback is a culture. It destroys the egocentric attitude over the people.
We mention that most of the developers and QA engineers focus on the application internals. So they make their optimization process through the application lifecycle. However, the techie role could not consider how the business flows the application. The re-platforming project might on sight. When reconsidering the “Account Creation Scenario”, we don’t implement only the functionality. We also make an abstraction. Use interface for validation and refactor gsm number name to AccountCredential model.
Creating a Semantics for Project
We need models quickly to achieve any requirement. Eric Evans points out that models should not be perfect. They are open to evolving and must be practical. We can produce reusable components from these models. It has to be transparent, so business roles can easily assure any effort on the application. Before the model construction, we do a workshop to construct literature before the crunching ideas. This workshop, called “Event Storming”. It is a crucial part of Domain-Driven Design(DDD) methodology because all the system internals have been defined at this session.
What Happens in Event Storming
The modeling process starts from a white-covered wall. There is a timeline on that wall. All the participants — regardless of roles — share their idea via colorful stickers. However, there is a terminology at the event storming correlated DDD concept. All the models constructed from Domain Event, User, Command, Aggregate, External System, and View units.
The first part starts with defining “Domain Events”. What happened on our application lifecycle. Wallet application begins with an Account Created event. However, events can not occur standalone. They need some interactions. Interactions can be command also be another event. Commands are the user interactions on the system. If we fire an Account Created event, we can point that the Account Create command has been fired by the user.
While identifying the domain objects, we need to regroup these objects into a single unit called Aggregate. Aggregate is the state machine of the system[1]. It is an abstract and takes commands and produces events related to its context[2].
The definition forces us to not defining the object at the beginning because we can separate responsibilities between domains. Account Created event has not to execute another logic on a different domain. It can be irrelevant to others. Unit definitions can allow us to draw the boundaries on our domain at the end of the day.
Conclusion
People in the project have leak knowledge at the beginning. Individual actions are inadequate because information only gathered into one person. Moreover, the team must be open to the reorganized maneuvers to make knowledge to be fragmented. Event storming is one of the reorganization action, and it starts to make a ubiquitous language from fragmented knowledge. Remember that while the feedbacks construct the shared language, the clues of implementation can be revealed.
Stay tuned :)
[1]A facilitators recipe for Event Storming
[2]Martin Fowler — DDD Aggregate
[3]Command vs. Event in Domain-Driven Design
