Building a software as a product for end users can go through two paths; getting things done and, and getting things done the right way. It can be argued that as long as the end product works, and does the thing it needs to do, nobody really cares how the product is built. It is not necessary that the product that was built to get things done, is done the wrong way. However, if the end product is built hastily without thinking of problems that could arise in future, it will result to a technical debt that will have to be paid in future.
The concept of Domain Driven Design(DDD) is not new. Eric Evans introduced DDD in his book “Domain Driven Design : Tackling Complexity in the Heart of Software” in 2003. As mentioned by Eric, “Every software program relates to some activity or interest of its user. That subject area to which the user applies the program is the domain of the software.”
“the region or field that a company provides service for can be called the domain that company is trying to cover“
In my perspective, the region or field that a company provides service for can be called the domain that company is trying to cover. E-Commerce, Payment gateway, booking systems are some of the common domains that many companies work on. A particular domain will have some common functionality. For example, e-commerce site will have a basket, product, and customers can make order to say the least.
“Models are merely tools to portray the knowledge and highlight the activities / behaviours of the user”
To create a software that caters all the needs of end user, a development team should first and foremost be able to visualise all the possible activities of the user. The complexity of information can be overwhelming. Models are merely tools to portray the knowledge and highlight the activities / behaviours of the user. Eric Evans mentions these models as “selectively simplified and consciously structured form of knowledge.” These models are programming language agnostic. Domain model itself are not a diagram but rather the idea that the diagram shall convey.
Software development process that is driven by these models can be considered as domain driven development.