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.