Designing our DDD refactor
Before we get started with laying out the DDD refactor, it bears mentioning that as the code stands right now, DDD is probably a bit much for it. A DDD approach is good for complex domains and large systems, neither of which can really be said about the current bookstore app. You sort of have to use your imagination here and visualize this app being developed by multiple teams within a large organization, with each module being owned by different teams. With that kind of backdrop in place, a refactor like this makes more sense and is a better fit for the DDD problem set.
The two major goals for our refactor are as follows:
- Enrich the model and have it be more representative of the problem domain, using DDD building blocks such as entities and aggregates.
- Split the application into four separate bounded contexts for customer management, inventory management, credit processing, and sales order processing.
Before we jump into the code, it makes sense to do a little modeling...
