Be Careful to Use Domain Driven Design!
I recently worked on a system capable of integrating with other businesses, implementing and designing projects with Domain Driven Design principles. Before delving into this article, ensure you have a solid understanding of Domain Driven Design.
My Quiz Management Special Context
In my context, I developed a learning management system, which required a quiz management system for its users, be they managers or learners.
The process involves a quiz definer defining a quiz, designers designing it, and participants and correctors fulfilling their respective responsibilities to complete the process. This project was undertaken at NOVIN SYSTEM company.
Now I need to explain most important requirement for continuation article.
Types of Sub-Domain
At the initial stage of design, after identifying and understanding concepts such as problem space, solution space, and problem domain, lets look up to three main types of sub-domains emerge.
Core: that part of domain which involved with business rules and logics and if it exist on system it have powerful complexity!
It have strong relationship with value proposition of business model canvas, maybe be anything like software, website (I just example software or website because its my own industry job. you can choose or imagine anything you think.) and it can say: “so I have this core and because of that you must choose my brand and my core section than my competitors?!”.
Let me look at perfect example. you need a system that matches drivers and customers which we have it with name of UBER (in my country, SNAPP!), is a C2C valuable business and good example for our core sub-domain. imagine its complexity!
You need a system to match their requests to drive or move at specified location to another location.
This system can be core domain of uber which create a value and solve demands.
Support: ok now you have a core sub-domain and it needs some dependencies and actions for working good (Read it Perfect!), DDD specialists tells that support and it have clarify name for understanding “What Does it Do?” and it just can support core to be done. lets back to pervious example, uber need a website or mobile application for customers to see that matching in their phones and tech their like (not any).
The website supports core matching system to business to flow!
Generic: everything is ok, core and support works fine and not we decide to think about things which other businesses think too. general concepts shared to all businesses and have such powerful complexity, implementing them can be so hard for normal people and seniors comes up now! uber have matching system and its mobile application supports that and it need to concerns about some important things like security of mobile application or website and it is a generic sub, all businesses done that for their system.
Just for a Simple CRUD?
DDD created to manage complex contexts and powerful business logics in type of systems and you need to be careful for using DDD concepts and right detecting sub-domains because of they are define such concepts like rich-anemic models at implementation and behavioral systems! when you have a simple CRUD software which may work with other systems like my context in beginning of article, creating rich models with wrong detected business logics and sub-domain is just bullshit!
My core was learning management system and quiz management is just a support or even generic sub-domain, I defined quiz management as my core sub-domain and its models rich. in my context I have less complexity in support than my core and I had a big mistake and it is taking my support sub as core sub. according to it I add some exceptional validations which they are not exceptional, because of exceptional situations just for important business rules and logics.
Logics like “Question of Quiz Cannot Have More Than 8 Choices” are not business logics and just some validations in every real work examples! you most understand and accept it a sub-domain is core or not or anything can be. then you can decide to set your implementation rich or even anemic (anemic have perfect advantages for some contexts).
Big Bad Consequences
Now imagine I implemented my quiz management design and stupid event storming sessions, have a numerous implementation with OOP and wrong being rich models with a lot of wrong behaviors and protections. I created application services and realize what a mistake I made!!!
It was a simple CRUD with easy logical validations and I add behavior — rich action concepts to that for nothing. wrong behaviors, wrong protections, wrong complexity and now I must to develop and maintain that. DDD create for run from brown-fields and fight with that, otherwise when you create software with green-field situation everything is good and you solve complexities you created for nothing.
But when you need to maintain that and event scale you messed up :)
What Should We Do Now?
Before every action you do … STOP! take a think for what are you doing and why? ask popular powerful questions may be saw before in Greg Young’s Blog:
What is the smallest possible thing we can do to deliver this business value?
What is the need this system fills, not “what it does”
If I turned off the server tomorrow who would be the first person to notice and why?
How would you verify that this is working correctly?
what is the earliest point you can know whether the system has any value to you? How will we do this?
Why are we starting here?
Take a better look, after definition your problem space and solution space and pass starting steps, think about sub-domains and decide carefully to create green — maintainable system. implement them and so on.
Need Better References?
Domain-Driven Design Tackling Complexity Software
Patterns, Principles, and Practices of Domain-Driven Design
Domain Driven Design With .NET CORE Packt Book
Conclusion
Before the end I need to thanks from my dear friend Mohsen Delavari and his guides which valuable for me. maybe you find out my solution story in a lot of references or books and I am about new to DDD but I would like to share this feeling of sadness or anger with you and:
At Final Keep it Simple!
Happy Designing.
