Domain-Driven Thinking
One of the toughest challenges that I faced within the digital universe was to “shift my mindset”. There is a continuous change and it is so fast, it feels like consuming all of the data streamed through the pipeline is impossible. In such an ever-changing environment, It is even harder when you try to shift the entire organization’s mindset.
Domain-Driven Approaches are one of the hardest mind shifts for the ones coming from anemic domain models background. The DDD approach is conceptually difficult to understand for most of the development community and it requires investment. If you invest in clean code you will not be thinking any other ways. It pays very well.
Commonly said, startup organizations start very small and they are growing over time. the luckiest ones are doing it pretty fast. They are executing a lot of tasks with very limited resources and they have to increase the resources very fast in the scale-up period.
In such a world, founders have to wear multiple hats, I remember that I was acting as the promotion guy right behind a stand and trying to convince people to experience our product. At the same time, I was the Head of Product who is passionate about bringing disruptive products to the market. Let’s try to highlight what I mean by shifting mindset with a story.
Start Our Story of a Startup
I have an idea, yea that is the beginning of everything, and want to transform it into a product, yes I am a developer and can code it. I need to find a Co-Founder to create business strategies and plan marketing activities.
Oh God, finally, have my Co-Founder with me and we are ready for the flight. I am self-motivated and started coding it.
“It’s the music to my ears”
Let me read this to you, you will have to perform the following tasks (maybe more):
- User Experience Design
- Competitive Analysis
- Prototyping
- Business Analysis
- Backend Development
- Frontend Development
- Mobile Application Development (Most probably go for Cross-Platform Solutions — Flutter or React Native)
- Dev Ops
- Sec OPs + millions of daily issues
It is not an issue, I already said that to you, I am motivated enough and I am a naturally born coder. I can work days and nights. Let’s plan everything and create a road map for us. We come together and created a road map with 1.500 items. Do not panic, keep the momentum and have a can-do attitude.
Finally, we started the coding phase, I have read Clean Code, The Big Blue Book, The pragmatic programmer, etc., and had a lot of Pluralsight, Udemy, Coursera training. Graduated from one of the top universities. I will implement best practices and it is in my pocket.
I developed the product within 6 months. It is pretty fast, isn’t it? but It is getting more difficult to develop new feature requests. I am planning to hire 2 developers to maintain the codebase. They started but why it is so difficult to onboard them? This is the best codebase I have ever seen, aren’t they the right people for me?
Hold on we are producing more bugs every day, there is something wrong with the process. Our traffic is increasing and it is very difficult to scale. Oh god feels very nervous. HELP ME!!!!
“SORRY. This is the Only Code Base You’ve ever seen” and this is an ongoing process in which you will always have a better version of it. It never ends😄
You will face more issues over time if you:
- did not document what you are doing
- did not code unit/integration test — meaning low test coverage ratio
- did not implement coding patterns
- did focus on your database too much
- did not focus on scalability
- did not focus on high availability
- did not have a tech stack fitting your needs, requirements
- did not optimize it from the beginning
Every missing part in these bullet points can be called as TECHNICAL DEBT that you are going to be paying at some point, most probably during your very stressful peak period. This is where Domain Driven Thinking comes to the scene. As your codebase grows and the load on your application (the pressure) gets harder your debt will be a barrier in front of you and it blocks your growth.
What the Hack is Domain Driven Thinking?
Domain-driven thinking focuses on the domain as its name clearly states. Instead of starting with a focus on the technical implementation details, it questions and criticizes the business itself. The main actors in domain-driven thinking are the Domain Experts. They drive the shape of the product. You need to listen to them and understand the direction that they would like to follow.
(!) This does not mean that it ignores technical components, handles and organize them based on the definitions provided by Domain experts
Domain-driven thinking requires you to put the input provided by domain experts in the center of your thinking and figure out the best way to translate them into code. the best way means a maintainable, testable, and clean way of coding.
Hence, communication is the key element in success for many aspects of our lives. This thinking requires you to build a common language for all of the team members and stakeholders called ubiquitous language. The vocabulary used in this language should be documented and kept up to date by the team over time. Bear in mind that the language can get more sophisticated as you grow and do not forget to implement the KISS (keep it simple stupid) principle.
What does the domain mean then? The domain focuses on a part of your application, it can be thought of as a subject that is solving a problem. It requires modeling your application by pieces, but dividing it into pieces is just part of domain-driven thinking. CONTEXT is very important and it defines the limits for your domain.
Domain-Driven Thinking in Practice
I can hear you are saying that Let’s go deeper and give us an example.
We can try to model a user profile. In traditional ways, we start doing this by creating a database schema. This is the first challenge you need to cope with. You have been doing this for years and you are pretty sure it works for you.
The database is just an implementation detail for you and you’d better leave it like that. Do not focus on the DB tables instead think about a clean model that constructs your domain, in this case, the USER. That is why your new first step is to talk to your Co-Founder — who is your domain expert in our startup example. Have all of the required information from him. Focus on WHAT HE IS SAYING because you already know how to model the database but the most important thing is to understand the business model and transform it into code in a clean way that fits a design pattern.
Have a session with the Domain Expert and started asking questions to him:
- What is a user for you?
A user is a person and there might be different types of users with a variety of permissions to perform actions in our system. The first type of user is basic, they can log in to our system and list our catalog but can not pick items.
2. What types of users do we have?
We have -3 types of users. The first type is basic and basic users can sign in to the system and have access only to the basic free content. gold users can access all of the basic content and 20 pro content per month. Platinum users have unlimited access to all of the content.
UBIQUITOUS LANGUAGES
Let’s build our language based on this discussion:
User: an account record created for a person who is using our application.
User Type: Group of users that can define their permission levels.
User Permission: A control mechanism that is making decisions for the actions users can or can not take on our system.
User Package: Represents a group of users that has different permissions. User packages have pricing on them and they are sellable assets with different limits. A package can also be free as well.
Objects Do not have to have IDs — WHAT?
The user has an email address stored in our systems and we are performing some kind of validations on this field. This means that the email address property has its own business. We can use this business multiple times in our system. Can we create a VALUE OBJECT for this?
Is it the first time, you ever heard about Value Objects? Let’s start with a definition of a Value Object.
Value Objects are objects that have no identities. Here is another challenge for you. I hear you are saying that the world is tough on you. Listen carefully then, they are trying to say to you that the value objects have no CONCEPTUAL identity. Simply, identity is not a concern for you while talking about the value objects.
To clarify it in your mind, check an important part of the definition by Eric Evans:
“Value Objects are instantiated to represent elements of the design that we care about only for what they are, not who or which they are.”
NO ID means that Value objects should be compared with values instead of IDs.
Is it crystal clear now? If not check out the references and read more about the concept.
Value Objects
https://enterprisecraftsmanship.com/posts/entity-vs-value-object-the-ultimate-list-of-differences/
https://enterprisecraftsmanship.com/posts/value-objects-explained/
https://deviq.com/domain-driven-design/value-object
To Sum UP
This is not the end but it is a good place to give it a break. I will continue to the story. Follow US.
