Domain-Driven Desing: Context Mapping and Tactical Design
Domain-Driven Design it’s an approach that brings together concepts, techniques, and principles where the understanding of the business is the main concern. It focuses on knowing well the problem the software aims to solve, helping build applications that reflect the real understanding of the domain. This concept was presented by Eric Evans in the book “Domain-Driven Design Tackling Complexity in the Heart of Software”.
On DDD communication must be clear and concise, in a way that everybody involved has a real understanding of the terminologies, processes, and business intentions. That brings us the concept of ubiquitous language, a language that is shared and developed by everybody involved in the business. It’s an omnipresent language used to unify communication and guarantee that specific terms are understood by everybody. Ubiquitous language is used inside delimited contexts based on specific business areas, defining boundaries where the language can be applied.
But how can we apply DDD in the real world? We can think about a fictitious movie theater called “Golden Cine”, with four theatres that exhibit movies from Fridays to Mondays. It’s a very traditional movie theater that still doesn’t have an online ticket sales system, and now wants a website where the customers can see now-playing movies, schedules, and buy tickets online.
Staff from Golden Cine must have access to the platform to include the movies, theatres, and playing schedules. Customers can register on the website and be able to see the movies, schedules, buy tickets and pay them online. The movie theater has also special prices for students and senior customers.
Context Mapping
On Domain-Driven design the Context Mapping demonstrates a global vision of business areas, and in the movie theater business case we can think about two big contexts. The Operational part, where staff can include the movies and the playing schedules, and the Sales part, where customers can access to purchase tickets and perform the payment.
In the Operational context the Employee is the main actor and is capable of including movies informing data like name, movie category, and parental rating. The four theatres will also be added with their names and the maximum capacity. Each weekend an employee will include what movies are being displayed with the date and time.
Sales context is the one the customer has access to buy tickets. He/she can register, informing personal data like identity and e-mail. Customers can see the movies, buy tickets and pay online.
Every time a ticket is bought the number of sold tickets must be controlled, in a way that no more tickets are sold than the max capacity of a theatre. This control is a responsibility of operational context, controlling how many tickets were sold in each playing.
Defining contexts also helps us to define the ubiquitous language, naming all items that belong to each context. The language used in the system must be the same used in the day-to-day, to facilitate the understanding and communication between developers and other people involved in the business. For instance, this movie theater uses the word “ticket” so developers should not create classes to represent it using words like “coupon” or “voucher”. The same language used in the real world must also be used in the software. Also, it’s important to mention that the ubiquitous language must be defined for each delimited context because the same term could have different meanings.
The communication flows from the Sales context to the Operational Context. A customer is capable of visualizing movies being displayed, stored in the operational context. When he/she buys a ticket, a request is sent to the operational context that does the reservation and controls theatre occupancy.
The relationship between these contexts is a Shared Kernel. Sales context needs to consult playing movies in the operational context, so sales context receives data from operational context. Sales context sends to operational context a notification every time a ticket is sold, so it can control the amount of sold tickets. Entity PlayingMovie is something shared between contexts.
Tactical design
Now that we have the delimited contexts we can start the Tactical Design, a set of resources used to build the domain model. It contains building blocks called Entities, Repositories, Value Objects, Factories, Services, and Aggregates.
Using the Golden Cine example, we can think about the following building blocks that will help us to project the system:
Entities
Entities have a unique identity, which represents something that needs to be differentiated from each other. For instance, the movie “Bad Boys” can refer to a Sean Penn dramatic movie, released in 1983, or to the action-comedy trilogy starring Will Smith and Martin Lawrence. The same applies to Customer, two customers can have the same name, but they are not the same person.
Repository
The repository offers an abstraction to the database used by the system, performing the entity's persistence and communicating directly with the data access. In the movie theater case we can have a movies repository and the interfaces to provide the now playing movies, for instance. We can also have a repository for customers with interfaces to include or edit data.
Value Objects
Value objects do not have an identity and are immutable, they are represented by their values and attributes. The movie theater has four theatres that will be included in the system once, and will never change.
Also, the movie theater has special prices for students and senior customers, and we could have a value object representing the ticket type, with discount policies.
Factories
Factories are responsible for building other objects and creating entities. We could have factories to createMovie, createTheatre or createCustomer, receiving data and building the proper object.
Aggregates
Aggregates are collections of entities and value objects, they are items in the domain that involve more than one entity. The objective of an aggregate is to model items from the real world with complex relationships.
In the Golden Cine example one aggregate could be the playing movie; it brings together information from the movie and the theatre, with playing schedules.
Services
Services perform specific operations in the domain, executing some logic. The customer can search for playing movies, and this could be a service. Also, every time a ticket is sold a service can be called to control the number of tickets and avoid the movie theater from selling more tickets than a theatre capacity.
In these examples we could see the definition of Domain-Driven Desing and how we can define the contexts and model the tactical design. In the next article we will see examples of how to apply design patterns (specially GRASP and SOLID) using this same business case.
