We have been careful to build a meaningful domain model - one that is understandable by all interested parties, from stakeholders to developers. It would be a shame to throw away all that effort by building, or implementing, a system that didn’t use that knowledge. Here are some guidelines to keep in mind as you implement your software system.
Interpret Your Domain Model for Implementation: Key Guidelines
Once you've got a domain model, you can see your system more clearly and make important implementation decisions, like the following!
#1: Be Aware of Separate Domains
It’s possible to have different bounded contexts within a domain. In the library system, there is one set of functionality that the librarians use and another for the patrons. The domain encompasses both of these bounded contexts under a single domain.
What does this mean for implementation?
You'll have to take these separations into account. To clarify, let's look at another example: Imagine you have been hired by the IT department as a developer. They look at you as having programming skills, etc. You are also part of the entire organization, so the human resources department knows about you too. But to them, you are a salary and benefits, and someone who has to be invited to the company picnic.
If you were to be implemented, you would be a different concept in each of those departments, even though you are the same person. There would be clear boundaries. The human resources department is not going to assign you a coding project, and the IT department is not in charge of giving you extra vacation days at your annual review. These different contexts will affect how you implement the idea of you in your system.
#2 Define Entities in Order to Represent Unique Objects
Speaking of you being an individual, remember how we defined the uniqueness of items in systems as entities? It bears repeating because it's important: these are the items that have a long-term identity that are consistent. You would be an entity at the organization that hires you. Even if you change many of your attributes (your name, hair color, salary, job title), you are still a unique entity. Implement these accordingly!
Also, entity objects are typically used by more than one use case. Therefore, they are usually saved to some sort of persistent storage (like a database). In the library system, the individual patron accounts and books are entities. By defining these items in your model, you'll have a much easier time making the right implementation choices!
#3 Identify Value Objects in Your Model
On the other hand, an item that changes over time and isn't unique is called a value object. An example would be the fine for an overdue book. If the fine were increased because the book was returned damaged, you would throw away the value object representing the original fine, and replace it with a new one, which now includes the cost of replacement. Or, if you needed to represent the fine in a different currency. You would substitute the fine value object (Euros) with another (Pesos). The original (Euros) object no longer has meaning/usefulness for you.
In other words, value objects are meant to hold a value. If that value is no longer needed, it is deleted and replaced by another. Value objects are usually only created to facilitate the execution of a single use case. Unlike entities, they are not persisted in data storage since they are only needed briefly. For the example above, the fine is probably calculated from the number of days that the book is late. There is no need to keep an object around and update it every day. But it is needed, at least briefly, for calculating the fine.
#4 Identify Aggregate Objects to Glue Things Together
Finally, you need objects to maintain sanity in the system. With all these entity and value objects floating around, they are usually related in some way. Here, aggregate objects come to the rescue. They hold entity and value objects that belong together so that you can treat them all as if they were a single concept. An example of this would be a list of overdue books:
First, there are the patrons (entities) that haven't turned in their books. Second, you have the books (entities) themselves. Then you have the money (value) they owe. You need to tie all these things together into a single, cohesive idea. To do that, you introduce the aggregate object "late book." Note that it has a "1" relationship with all of its connecting parts. This isn't always true for an aggregate, but it is typical.
Implementation: What's next?
Now that you have your bounded contexts, entities, value objects, and aggregates, you move on to coding. But you have a real leg up on building the system. Since you've defined all these items, you should have a clear understanding of what each object does, and what it represents.
In the library system, you've seen the tip of the iceberg in terms of how a domain model and domain-driven design can help you.
You only have one domain (the library system) and two bounded contexts (the librarian system, and the patron system). You also only have a handful of ideas in each (patron, book, etc.). However, this already helps you organize your thought-process when coding. Once you start working on large corporate-wide or inter-corporate systems, understanding and splitting domains become essential in creating understandable, modifiable systems.
Let's Recap!
We've gone over some of the key elements to identify once you've completed your domain model:
Entity objects - those that are unique in the system.
Value objects - those that do not require uniqueness.
Aggregate objects - that tie entity and value object together, to complete a use case.
Also, when implementing, you need to be aware of bounded contexts, so that you code up your solution in a way that makes sense for your system.
In the next chapter, you'll get a quick recap of what you've learned in this course. Once your memory is refreshed, test your knowledge in the end-of-part quiz!
