How to aggregate repositories?

Question

I am working on a large-scale system for a telecom company. I am new to DDD and having hard time linking different pieces together. Our current system is build using NHibernate. It currently has well over 600 tables and all data access is done using NHibernate but for the new system we will be using EF. Below are few functional areas and examples of database tables in each functional area.

Customers
-----> CustomerDemographics
-----> CustomerPayments
-----> CustomerTransactions

RoutingEngine
-----> InboundRoutes
-----> OutboundRoutes

ProvisioningEngine
-----> InboundSwithces
-----> OutboundSwitches
-----> RouterConfigs
-----> GatewayConfigs

BillingEngine
-----> InboundTraffic
-----> OutboundTraffic

Since the system has to be unit-testable, I started abstracting actual entities with a repository pattern. One approach is to create one repository object for each each database table. Of course all these repository classes could be derived from a generic repository interface. However this will be adding quite a bit of overhead in terms of code base maintenance. In DDD, I read about this concept of Aggregates but I am not sure how it should be applied specially in context of EF. Should the Aggregate objects are container of these repositories or are these more of a container of related contexts (meaning something along the lines of Bounded DbContexts)?

Answer 1

One approach is to create one repository object for each each database table.

In DDD, with the notion of persistence ignorance, database tables typically aren't in a one-to-one mapping with repositories. Instead, repositories should be one-to-one with aggregates.

Of course all these repository classes could be derived from a generic repository interface.

The repository pattern can be a slippery slope. While it is great for encapsulation, it is easy to get carried away with needless abstraction. Take a look here for an alternative perspective.

Should the Aggregate objects are container of these repositories or are these more of a container of related contexts (meaning something along the lines of Bounded DbContexts)?

It seems that what you call "functional areas" are called bounded contexts (BC) in DDD. (Not DbContext in EF). Also, aggregates aren't containers of repositories, they contain a group of related entities from your domain model. The stereotypical example is the sales order model where you have an order aggregate which consists of the order aggregate root and various entities and value objects such as order line items. As stated above, aggregates are the domain objects which repositories should provide access to. Therefore, you should structure your repositories around aggregates, but of course first you have to identify your aggregates and BCs. Take a look at Effective Aggregate Design by Vaughn Vernon.

Also, Having 600 tables in a single BC seems like too much and is a potential sign that you have multiple BCs at play. What BCs achieve is functional cohesion, which in turn is most fitting way to group ("aggregate" conflicts with DDD term) your repositories.

Answer 2

Aggregates in DDD are consistency boundaries - islands of transactional consistency. When you have a cluster of objects in a domain model that should be kept transactionally consistent and can be treated as a meaningful conceptual whole then you likely have an aggregate. Across aggregates you can have eventual consistency.

If you are doing new development, I would recommend initially modeling your domain in objects first, then work out what the database schema should be as a later pass.

I would recommend breaking your one huge model into many more specialized domain models, perhaps along the broad lines of functional areas, noting carefully what key business scenarios each model is intended to handle (i.e. what hard business problems are you trying to solve with each model). Each model will need to have a good boundary around it (i.e. it should be within explicitly defined bounded context), where it is clear what belongs to one model and what belongs to another. This is usually accomplished by aligning the model boundary with some kind of subsystem boundary (architecturally speaking).