What is Domain-Driven Design?
Domain-Driven Design (DDD) is the approach to software development that enables us to translate complex problem domains into rich, expressive, and evolving software. It's how we design applications when the needs of our users are complex.
Conceptualized by Eric Evans, who wrote the bible of DDD (known as the Blue Book), DDD's primary technical benefits are that it enables you to write expressive, rich, and encapsulated software that is testable, scalable, and maintainable.
The main elements of DDD are:
1. Ubiquitous Language
The Ubiquitous Language can only be learned by talking with domain experts. Once agreed upon, it enables developers to connect the software implementation to what occurs in the real world.
2. Entities
Domain objects that we care to identify. Things like User, Job, Vinyl, Post, Comment, etc. Entities are compared by their unique identifier (usually a UUID or Primary Key).
3. Value Objects
Value objects have no identity. They are attributes of Entities. E.g., Name as a Value Object on a User.
4. Aggregate
These are a collection of entities bound together by an aggregate root. The aggregate source is the thing that we refer to for lookups. No members from within the aggregate boundary can be referred to from anything external to the aggregate. This is how the aggregate maintains consistency.
5. Domain Model
Domain and model have their meanings in domain-driven design. Domain refers to the details of the problem you want to solve. The knowledge about the business, its operations, terminologies, rules, goals, and objectives. By knowing all this, the problem is defined.
6. Domain Services
This is where we locate domain logic that doesn't belong to any one object.
7. Bounded Context
Bounded context is a central pattern in domain-driven design that contains the complexity of the application. It handles large models and teams. This is where you implement the code after you’ve defined the domain and the subdomains.
Bounded contexts represent boundaries in which a particular subdomain is defined and applicable.
8. Repository
We use repositories to retrieve domain objects from persistence technologies. Using software design principles like the Liskov Substitution Principle and layered architecture, we can design this in a way so that we can make architecture decisions to switch between an in-memory repository for testing.
9. Factory
We'll want to create domain objects in many different ways. We map to domain objects using a factory that operates on raw SQL rows, raw JSON, or the Active Record returned from your ORM tool (like Sequelize or TypeORM).
#technology #softwareengineering #programming #techworldwithmilan #ddd