.NET Domain-Driven Design with C#: Problem – Design – Solution

Chapter 4. Companies and Contacts

Last Chapter I showed how both Companies and Contacts were part of the Project Aggregate. Since the focus was on the Project Aggregate, not much was done with these two Entities. This chapter, I will dive in and take a deeper look at the Company and Contact Aggregates, and I will show how they relate to the Project Aggregate.

The Problem

One of the problems with the legacy application is that it does not handle tracking Companies, Contacts, and their associated Addresses very well. The current system does not allow multiple Addresses per Company or Contact, and as a result the users are often entering the same Companies and Contacts into the system as duplicate records in order to show a different Address for the Company or Contact.

With that being said, it sounds like a database issue of having denormalized data. It is not the point of this book to dwell on the database design; I believe that the focus of the problem needs to be on the domain model. If the domain model is designed properly, it can handle this problem. Remember, one of the tenets of Domain-Driven Design, which I discussed in Chapter 2, is persistence ignorance. Therefore, the application's data store could be a text file for all I care, because it is abstracted away by the Repository Framework.

The Design

In the SmartCA domain, the purpose of a Project is to bring together and manage all of the people involved in the construction process. In the next few sections, I will be designing ...