Search code examples
c#entity-frameworkdomain-driven-designddd-repositories

Multiple DataContexts for a database with cross-schema relationships

Scenario:

I am tasked to do a desktop application which has to run over a local network settings such that the database and Back-Office parts have to reside on Server while POS clients making calls to the server for operations.

There are 64 tables in the database with 8 Schemas in which tables in one Schema have relationships across other Schema's tables.

Schemas

  1. Accounts (Chart of Accounts, Transactions, Journals, Bank/Cash/Deposit Vouchers)
  2. HumanResources (Departments & Employees)
  3. Purchasing (PO, PO Details, Purchase Returns & Details)
  4. Sales (Sales, Sales Details, Sales Returns & Details, Customers)
  5. Stock (Product, Inventory, History for changes in cost, prices, inventory transfers)
  6. Tax (Tax Groups, WHT Tax, GST etc)
  7. Security (for users, permissions, and session's logging)
  8. Store (Store Profile, Terminal, Section, Rack, Shelf, Bin)

Notes: There are concerns, over using one DataContext for such a large database that has to run on network, that navigation through that model would deteriorate performance of application. Hence, we should break down the data contexts; for which an intuitive strategy is to create one DataContext (8 in this case) for each Schema in the database and exchange data to/fro other contexts through Services Layer. My design is based on DDD.

Question: What do you think should be the appropriate strategy to break down the DataContext for the given scenario? I want to learn the experienced insights around the issue.

PS. I am using Entity Framework 5.0 over .NET Framework 4.0 as the client required.

Solution

  • Your domain/business knowledge will just be as important in defining the breakdown of the data contexts. In DDD, you can use the Single Responsibility Principle to separate the subdomains(business capabilities) into separate bounded contexts. It's good for POC but I expect in production you need to consider the legacy system (current prod system) as another bounded contexts. Just a thought.