0

我有构成调度系统基础的会议对象，其中的网格视图用于显示重要信息。这是为了安排员工参加会议，并让员工查看已安排的内容。

我一直在尝试遵循 DDD 原则，但我很难知道从我的服务层向下传递到系统的表示区域的内容。这是因为时间表可能很大，实际上由系统的许多不同元素组成。例如。客户名称、地址、案例信息、组等，所有这些都是会议安排者做出决定所需要的。

除此之外，调度程序需要更改此调度中的值并将其传递回服务层（例如，从下拉列表中分配员工，可能更改组等）。因此，信息并不是真正的“只读”——它需要与之交互。IE。这不仅仅是一份报告。

我们目前的方法是从 SQL 中填充一个扁平的“调度对象”，该对象由不同域对象的一小部分构成。这是一个相当复杂的查询。进行更改后，然后将其传递回服务层，服务将检索有问题的域对象，并使用来自 DTO 的信息在域对象上触发业务方法。

我的问题是，这是正确的方法吗？IE。继续从 SQL 生成大型自定义对象，然后从服务层向下传递到感觉很像视图模型的表示层对象？

由于答案而更新

了解所涉及的实体/聚合关系的数量。（这是一个混淆的例子，所以关系在这里很重要）

  • 客户端在一个默认组中

  • 客户有一个未结案，但许多已结案

  • 案例有很多会议

  • 会议有许多分配的员工

  • 开会有很多原因

  • 会议可以安排到不同的组

  • 员工可以与许多组相关联。

日程表需要加载属于与员工在同一组中的患者的未决案例中的所有会议。

调度程序可以查看客户名称、客户地址、案例信息、会议时间、会议类型、会议原因、调度组（showstrail）、分配的员工（也有隐藏的员工 ID）。

可编辑字段是分配员工下拉列表和计划组。

  • 日程表可能多达 200 行。
  • DTO 是从 WCF 下来的，所以域模型是在这个服务层之上访问的，而不是在下面。
  • 服务基于传回的 DTO 值利用域模型业务调用，并且存储库处理插入/更新。

所以，我想更新，是使用查询来填充一个包含上述所有内容的对象，可以作为一个合并的 DTO 传递下去吗？如果没有，您将如何处理它？（给出一些对服务层的调用示例，并解释一下您如何构思 ORM 获取数据并牢记性能）

4

1 回答 1

0

在服务层及以下，我会将每个实体（参见 DDD 中的聚合根）根据其事务边界分开处理。即，即使您可以在同一个 UI 视图中更新客户端和案例，最好先以事务方式修改客户端，然后再修改案例。您在一个事务中尝试修改的次数越多，您与其他用户的冲突就越多。

尽管您的日程安排很大并且可以包含很多对象，但服务层应该再次分别处理每个实体（聚合根），然后将它们捆绑在一起形成一个新的视图模型。可悲的是，在棕地项目中，很多逻辑可能在 SQL 中，并且大量的多表连接可能会使它更难重构为更原子的查询，这些查询完全符合需要。老式的以数据为中心的“在数据库中尽你所能”的观点与 DDD 的一切背道而驰。

因为 DDD 是设计思想和模式的集合，而不是特别是一种方法论或架构，所以尝试将当前应用程序硬塞到以 DDD 应用程序为中心的设计中可能为时已晚。听起来您当前的应用程序在以数据为中心的视图中非常根深蒂固。

如果当前所有内容都在一个整体块中通过层传递，最好保持这种风格，并将这些整体块暴露给其他团队中希望使用它们的人，以便在他们的新应用程序中使用。您可能能够放置某种视图模型缓存（有点像 CQRS 中的缓存视图模型元素）。

在我个人看来，以数据为中心的标准化数据应用程序已经过时了（它们在 1970 年代硬盘空间昂贵时才有意义），所有应用程序都应该朝着更现代的做法发展。实际上，只有当遗留系统陷入瘫痪时，利益相关者才会投入资金寻找替代方案（通常是在每台服务器都塞满 RAM 之后）。说服他们一次重构小部分可能是可能的或最好的。

于 2014-02-07T15:01:42.553 回答