Eric Evan's book Domain-Driven Design has become very popular in the last decade. Few teams claim to exclusively follow domain-Driven design, but many teams who are agile aware or keep up with the latest trends tend to adopt particular practices and philosophies from DDD.
The main goal of domain-Driven design is to tackle a complex domain. The premise is based on the thought that most software projects are overly complex and not understandable. This complexity is not due to the technical elements of the project such as networking, databases or platform, but rather the domain itself. The domain is defined as the core business activity of the user. In turn, the main philosophy of DDD is the primary effort for design of a complex project should be on the domain and domain logic, and complex domain designs should be based on a model.
Eric Evan's book enumerates several defined principles and practices, each of which is well thought out and applicable. In essence, that is the beauty of Evan's approach: that subtleties and gray areas of complexity become defined and named through domain-Driven design.
At its core there are a few distinct concepts which exemplify domain-Driven design.
- ubiquitous language
- domain model
- knowledge rich domain
- layered architecture
Ubiquitous language in its simplest meaning is the attempt to bridge the gap between the language of the business and language of the system. The motive behind the ubiquitous language is that the complexity of a project can become unmanageable when a business term or concept is part of the system but is not reflected with the same language in the objects of the system. This tends to create an understanding gap between the business experts who define the behavior of the system and the developers who implement the behaviors of the system. A project that uses the concept of the ubiquitous language strives to incorporate business names, entities, and terminology into their objects.
A domain model is another fundamental base of domain-Driven design. A complex business domain will result in a complex software project. In order to understand the business domain and translate that knowledge into an object oriented system, objects are necessary. A domain model is an attempt to capture knowledge learned about the business and turn that into objects. Note that the domain model does not have to be an exact depiction of the actual objects used in the system. Many projects maintain a "concept" domain model, which models the known entities, relationships and structure of a system. The main purpose of a domain model is to understand the business domain and build a visual depiction of knowledge so it can be shared amongst team members. It is not a detailed design diagram of the objects of the system but rather a precisely modeled understanding of the business in the form of objects. The domain model is a living diagram and is updated and maintained as understanding evolves.