13 Domain-Driven Design and other architectural approaches

 

This chapter covers

  • Three architectural approaches applied to the part 3 Book App
  • The differences between normal and DDD-styled entity classes
  • Eight ways you can apply DDD to your entity classes
  • Three ways to handle performance problems when using DDD

Although this book is about EF Core, I want to include something about software architecture, as readers of the first edition of this book found it useful. You were introduced to the layered architecture in part 1. Now, in part 3, in which we are building a much more complex Book App, I’ll change the Book App’s software architecture to improve the separation of parts of the code and make the entity classes’ data more secure.

The most important of these architectural changes is swapping to the use of Domain-Driven Design (DDD), from Eric Evan’s book of the same name (Addison-Wesley Professional, 2003). The first version of EF Core added one new feature that EF6 didn’t have—backing fields—and that new feature makes following the DDD approach possible. Since the first edition of this book came out, I have used DDD a lot, both in client applications and in building libraries to handle DDD entity classes.

13.1 A good software architecture makes it easier to build and maintain your application

13.2 The Book App’s evolving architecture

13.2.1 Building a modular monolith to enforce the SoC principles

13.2.2 Using DDD principles both architecturally and on the entity classes

13.2.3 Applying a clean architecture as described by Robert C. Martin

13.3 Introduction to DDD at the entity class level

13.4 Altering the Book App entities to follow the DDD approach

13.4.1 Changing the properties in the Book entity to read-only

13.4.2 Updating the Book entity properties via methods in the entity class

13.4.3 Controlling how the Book entity is created

13.4.4 Understanding the differences between an entity and a value object

13.4.5 Minimizing the relationships between entity classes