In this chapter, we have gone into a lot of detail on how to separate out systems and how to deal with concepts throughout the application, mostly on the smaller scale of a project, and how it interacts with the larger scale.

There are many ideas that have been used in other places we can draw from when building the project, be it object-oriented design or be it software architecture patterns; the important thing to keep in mind is that nothing should be set in stone. One very important thing about domain-driven design is that it constantly changes, and that this change is a good thing. As soon as a project becomes too solid, it becomes hard to change and this means the business using it can no longer evolve alongside its software, which ultimately means switching to another system and different software, or rewriting the existing software.

The next chapter will touch more on the higher level view of the intertwining pieces of the project as a whole, going into detail about the context...