Key benefits of a domain-driven development model for Business Automation

Let me be honest upfront! I have a bias towards working on a domain-driven development model. Yes! I do mean customized, strongly typed entities and not .NET CLR types (typed datasets, datatables, etc). Yet for years, due to preexisting project infrastructure and libraries I have had to develop and enhance software that follow a loosely typed development model along with all its pitfalls.

It took the introduction of Microsoft’s Entity Framework and ASP.NET MVC for the same powers that be, to suddenly wake up and espouse all about domain-driven development. Naturally, I am not the one complaining. 😉

I am currently reading Phil Haack’s co-authored book, Professional ASP.NET MVC 3, enjoying and referencing it for my current projects.

Finally I am being able to develop software with renewed passion!

The standard joke about software development is regarding the lack of understanding between stakeholders and the software developers. These days, Agile methodology of software development is the rage. This requires a close interaction between a domain expert and the development team in short multiple iterations. As a result, the amount of documentation done for recording requirements is lesser than in the waterfall approach.

Software systems like the business domain have objects that have properties, behavior and interaction. In Domain-driven development, the key aspect is to conceptualize software objects similar to the business domain, using the terminology that domain experts use.

It also pertains to the “strong typing” of these software objects so that the business domain is explicit to the development team. Business stakeholders will always use terminology they understand. If the development team embraces the same terminology while conceptualizing the system, it will result in a domain-driven system that will be very close to the real world business model. There may be concepts for which it may not be easy to use common terminology. In such cases, the stakeholders and development team members must arrive at a consensus.

For example, the domain expert for a healthcare domain sees pharmacist, physician, administrator, nurse, care manager as separate and distinct entities. They have their own behavior and distinct interactions. However, a development team following a domain agnostic approach may just see a “user” entity and assign role as an attribute (and in some cases, a collection of roles for the same user). Such an approach may lead to confusion during development and user acceptance. The focus would shift from the software matching the domain and its workflow to making the client adjust to so-called reusable software developed. A very strong proof of such software is when the end user requires explicit training to use the software.

In the last decade, the datatables have been really popular because their attributes can be changed dynamically at runtime. This flexibility comes at the cost of making it confusing for developers to understand the business model since it is no longer explicit. Datatables also cannot prevent the violation of the principles of “SOLID” OOPS.

My personal opinion is that use of datatables has resulted in a lot of domain-agnostic code written under the perception of software reuse.

Listed below are some of the key benefits that I see in a domain-driven development model. I may have missed a few benefits, while there may be some who would argue against those listed below. Please feel free to share your thoughts with me! 🙂

Key Benefits

• When a development team is attempting to translate the requirements in terms of the business domain, chances are good that the analysis is leading to objects that closely model the business domain, tailored to the end user’s needs. This is opposed to a domain-agnostic approach in which we, as developers, start generalizing beyond the end user’s needs to develop the Utopian “one-tool-fits-all” software
• Requirements are always explained from a domain perspective. Conceptualizing the software system in terms of the business domain reduces the risk of misunderstandings between the domain experts and the development team. This also reduces the risk of ‘back-and-forth’ while freezing requirements
• When everyone is using the same terminology, keeping track of requirement implementation becomes a simpler task
• It becomes simpler for the domain expert to establish whether the software features map the business requirements in every release cycle (iterations in Agile)
• The direction of development is closer to the client’s needs
• The project has lesser chances of going off-track. This is usually established in UAT phases or showcases
• The coordination is more people driven (since everyone is using the same terminology) that is less top driven, ensuring fewer bottlenecks
• For a new development team member, learning the domain information can actually be less confusing because they will be able to visualize the domain in the software and be able to co-relate
• Last but not the least – when we develop domain driven, we end up with more readable code and lesser duplication. As an esteemed colleague of mine commented – “Code should be readable like a newspaper!“

 

Please feel free to share your thoughts me! Your suggestions may get incorporated into this blog (with due credits of course!)