具有跨架构关系的数据库的多个DataContexts

Question

情景：

我的任务是执行桌面应用程序，该应用程序必须运行本地网络设置，以便数据库和后台部件必须驻留在服务器上，而POS客户端则调用服务器进行操作。

数据库中有64个表，其中包含8个Schema，其中一个Schema中的表与其他Schema表之间存在关系。

架构

1. 账户（会计科目表，交易，期刊，银行/现金/存款凭证）
2. HumanResources（Departments＆amp; Employees）
3. 采购（采购订单，采购订单详情，采购退货及详情）
4. 销售（销售，销售详情，销售退货和详细信息，客户）
5. 库存（产品，库存，成本，价格，库存变化的历史记录） 转让）
6. 税（税组，WHT税，商品及服务税等）
7. 安全性（针对用户，权限和会话的日志记录）
8. 商店（店铺简介，终端，部门，货架，货架，仓柜）

备注： 有人担心，对于必须在网络上运行的大型数据库使用一个DataContext，通过该模型导航会降低应用程序的性能。因此，我们应该打破数据背景;一个直观的策略是为数据库中的每个Schema创建一个DataContext（在本例中为8），并通过Services Layer与其他上下文交换数据。我的设计基于DDD。

问题： 您认为应该为给定方案分解DataContext的适当策略是什么？我想学习围绕这个问题的经验丰富的见解。

PS。我使用Entity Framework 5.0而不是.NET Framework 4.0作为客户端。

Answer 1

您的域/业务知识在定义数据上下文细分方面同样重要。在DDD中，您可以使用单一责任原则将子域（业务功能）分隔为单独的有界上下文。它对POC有好处，但我希望在生产中你需要将遗留系统（当前产品系统）视为另一个有限的背景。只是一个想法。