13 Domain-Driven Design and other architectural approaches
- Three architectural approaches applied to the part 3 Book App
- The differences between normal and Domain-Driven Design styled entity classes
- Eight ways you can apply Domain-Driven Design to your entity classes
- Three ways to handle performance problems when using Domain-Driven Design
Although this is a book about EF Core, I want to include something about software architecture as readers of the first edition of this book found it useful. You have already been introduced to the layered architecture in part 1. Now in part 3, where I am building a much more complex Book App, I change the Book App’s software architecture to improve the separation of each parts of the code and make the entity classes’ data more secure.
The most important of these architectural changes is swapping to using 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, backing fields, that EF6 didn’t have, 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 building libraries to handle DDD entity classes.
13.1 A good software architecture makes it easier to build and maintain your application
13.2 Book App’s evolving architecture
13.2.1 Using DDD principals both architecturally and on the entity classes
13.2.2 Applying a clean architecture as described by Uncle Bob
13.2.3 Building a modular monolith to enforce the SoC principals
13.3 Introduction to Domain-Driven Design 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 What are the differences between an entity and a value object?
13.4.5 Minimizing the relationships between entity classes
13.4.6 Grouping entity classes – DDD name: aggregates
13.4.7 Deciding when the business logic shouldn’t be run inside an entity
13.4.8 Applying DDD’s bounded context to your application’s DbContext
13.5 Using your DDD-styled entity classes in your application
13.5.1 Calling the AddPromotion access method via a repository pattern
13.5.2 Calling the AddPromotion access method via a class-to-method-call library
13.5.3 Adding a Review to the Book entity class via a repository pattern
13.5.4 Adding a Review to the Book entity class via a class-to-method-call library
13.6 The downside of DDD entities – too many access methods
13.7 Getting around performance issues in DDD-styled entities
13.7.1 Allow database code into your entity classes
13.7.2 Make the Review constructor public and write non-entity code to add a review
13.9 Summary