Entry To Domain-Driven Design Fundamentals

Big Ball of Mud

BBoM is known as the state for software architecture that starts with a simple program that solves the customer problem but didn’t reflect the terminologies of the domain containing the problem desired to be solved.

After a series of feature enrolments and updates on software, the software architecture becomes more complex and harder to be recognized. In this situation, we say the software has become like a big ball of mud.

Image Source [1]

Definition of Domain-Driven Design

The term was brought by Eric Evans in 2004 by publishing the book “Domain-Driven Design: Tackling Complexity in the Heart of Software”.

Martin Fowler defines Domain-Driven Design

“As an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. “

It can be defined as well as

“the software development methodology that focuses on the core domain and domain logic using the domain model as Base of complexity and Constantly collaborates with domain experts.”

The concept takes a long time to move from theory to practice and event until today there some developers misunderstand some of its principles, I will try to simplify these principles in a few numbers articles.???????????????????????????????????????????????????????????????????????

Importance of Domain-Driven Design

Customer problems are known to be at the base of all product development. Yet if we speak to developers or product managers, they are often not very clear about the requirements. Here, the problem lies in the terminology. There are two terms buried in one-word “requirements”: customer needs and product requirements. To have this clarified, it’s important to understand a high-level concept: separating problem space from solution space.

So, let’s identify the difference between problem space and solution space.

Problem Space

problem space is where all the customer needs that you’d like your product to deliver live. You shouldn’t interpret the word “needs” too narrowly: Whether it’s a customer pain point, a desire, a job to be done, or a user story, it lives in problem space.

Solution Space

Solution space includes any product or representation of a product that is used by or intended for use by a customer. When you build a product, you have chosen a specific implementation. Whether you’ve done so explicitly or not, you’ve determined how the product looks, what it does, and how it works.

The Shortage in Development Process

The problem comes from that the Developers rarely have direct contact with a business owner. And take the requirements through the business analysts or product managers who talk to customers and summaries the discussions in the form of system requirements as an IT solution

the inputs from business analysts describe the solution, not a problem and most software development problems come from this part.

DDD is focusing to establish a philosophy to easily maintain collaboration space from requirement gathering until coding that guarantees to solve the domain problem.

Ubiquitous Language

A design approach described in Eric Evans’ “Domain Driven Design” (2003), which consists notably of striving to use the vocabulary of a given business domain, not only in discussions about the requirements for a software product but in discussions of design as well and into “the product’s source code itself”.

The reason behind this is to ensure that the domain language and terminologies are reflected in everything in the software even the code to make sure that the development process will remain collaborative between business users and the development team.

One of the most important things is to avoid implicit understanding for domain business and the golden rule here is to convert any implicit understanding to explicit understanding and make it clearer I will give example.

Let's say you design software for purchase orders in the order screen there are fields for a price, here the price field is not clear it can hold multiple-meaning it can be the selling price, buying price, or average cost.

This will open the opportunity to put an assumption by the development team and in the end deliver the wrong value to the customer.

The team must use ubiquities language with explicate understanding for

the core domain in the problem space.

Context

The setting in which a word or statement appears determines its meaning. Statements about a model can only be understood in a context. To make it clear will give example by the word “Product”

This word will be understood in different ways in different contexts?

Image Source[2]

Sales: For the salespeople, product means the sales price and maybe the margin.

It's where the company earns money, and other properties of the product aren't

that important.

Purchasing: If we buy a product to resell, we're mostly interested in the purchase

price, how many items of a given product the supplier has in stock, and how fast

they can be delivered.

Inventory: We're mainly interested in how many items we have in stock. If a

a specific item is out of stock, this context can keep the estimated date when it will

be back in stock. Here, we probably also define some internal properties of the

product, such as the item number.

Warehouse: It needs to manage the space that's required to store products, so

people in this context need to know when product batches arrive when

shipments to customers take place, how products are packaged, and where they

are stored.

DDD Best use cases

DDD is a great software design framework but is it feasible for all types of software applications?

The answer is no because it will not give many benefits in these projects: -

·????????Applications that have less business logic complexity and most of it is CRUD operations the DDD will be extra overhead without real benefit

·????????Highly Technical Projects like building firmware or creating a device driver the DDD will be extra overhead without real benefit.

Core Domain

The core domain is the main problem the software tries to solve, it is the selling process in an e-commerce application, it is patient scheduling in hospital appointment systems, it is courses in eLearning platforms, etc., generally, it is the thing that brings the most value to the users. Therefore, it is in the core domain that the focus should be. It should be crystal clear what is in the core domain and what is not.

Sub Domain

It is the complex domain in the system but not considered as the core domain it can be a supplementary helpdesk system in a hospital appointment system that is required but not core. for the subdomain, we can use one of these options

Off-the-shelf solution: Because it is not part of our core domain, we can choose to buy an implementation or use open-source software.?

Outsourced implementation: Another option is to outsource the implementation of this subdomain. This choice will free the core team to work on the core domain, while also allowing more development to be done without increasing the size of the team and without dissipating core domain knowledge.

In-house implementation: a homemade solution will provide just what we want and nothing more, as well as easy integration with the rest of the system.

To continue in the DDD journey the most important layer is the domain layer so this is the first part that needs to be designed, but before we need to tackle the domain complexity by the collaboration with the domain experts , to know how this can be happen kindly check this article

References

[1]????????S. Millett, N. Tune, and A. Denyer, “Patterns, principles, and practices of domain-driven design,” 2015.

[2]????????A. Zimarev, “Hands-On Domain-Driven Design with .NET Core,” p. 446, 2019.

[3]????????E. Evans, “Domain-driven design: tackling complexity in the heart of software,” p. 529, 2004, Accessed: Mar. 20, 2022. [Online]. Available: https://books.google.com/books?hl=en&lr=&id=7dlaMs0SECsC&pgis=1

[4]????????robloxro, “Summary of the Domain Driven Design concepts | by robloxro | Medium,” 2020. https://medium.com/@ruxijitianu/summary-of-the-domain-driven-design-concepts-9dd1a6f90091 (accessed Mar. 20, 2022).

[5]????????“Domain-Driven Design: What is it and how do you use it?” https://airbrake.io/blog/software-design/domain-driven-design (accessed Mar. 20, 2022).

[6]????????Martin Fowler, “DomainDrivenDesign,” 2020. https://martinfowler.com/bliki/DomainDrivenDesign.html (accessed Mar. 19, 2022).

[7]????????Nikhil Gupta, “PROBLEM SPACE vs SOLUTION SPACE. Customer problems, known to be at the… | by Nikhil Gupta | Medium,” 2019. https://medium.com/@nikhilgupta08/problem-space-vs-solution-space-f970d4ace5c (accessed Mar. 19, 2022).

?