Domain driven design 服务层DTO—大型复杂交互式报表类对象

我有一些会议对象，它们构成了日程安排系统的基础，其中GridView用于显示重要信息。这是为了安排员工参加会议，并让员工查看已安排的内容

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

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

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

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

因回答而更新

了解涉及的实体/聚合关系的金额。（这是一个模糊的示例，因此关系是这里的重要内容）

• 客户端位于一个默认组中

• 客户有一个打开的案例，但许多案例已关闭

• 案件有许多会议

• 会议有许多指定的员工

• 会议有很多原因

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

• 员工可以与许多组关联

计划需要加载属于与员工属于同一组的患者的开放案例中的所有会议

Scheduler可以查看客户端名称、客户端地址、案例信息、会议时间、会议类型、会议原因、scheduledGroup（showstrail）、分配的员工（还具有隐藏的员工ID）

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

• 明细表最多可以有200行
• DTO来自WCF，所以域模型是在这个服务层之上而不是之下访问的
• 服务根据传回的DTO值利用域模型业务调用，存储库处理插入/更新

---

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

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

尽管您的计划很大，可以包含很多对象，但服务层应该再次单独处理每个实体（聚合根），然后将它们捆绑到一个新的视图模型中。遗憾的是，在brown field项目中，SQL中可能有很多逻辑，而大量的多表联接可能会使其更难重构为更原子的查询，而这些查询正是需要的。“在数据库中尽你所能”这一老派以数据为中心的观点与DDD的一切都背道而驰

由于DDD是设计思想和模式的集合，而不是一种方法论或体系结构，因此，尝试将当前应用程序转变为以DDD应用程序为中心的设计似乎为时已晚。听起来，您当前的应用程序在以数据为中心的视图中非常根深蒂固

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

---

在我个人看来，以数据为中心的标准化数据应用已经有了自己的一天（它们在硬盘空间昂贵的20世纪70年代是有意义的），所有应用都应该朝着更现代的方向发展。事实上，只有当遗留系统跪在地上爬行时，利益相关者才会拿出资金寻找替代方案（通常是在最后一台服务器都塞满RAM之后）。说服他们一次重构一个小部分可能是可能的，也可能是最好的。

这个问题涵盖的内容太多了，你最好问一个问题，把内容至少缩减到四分之一。我暂时忘记了DDD和SOA，您上面描述的不是DDD或SOA。您通过web服务（特别是WCF）公开应用程序层的解决方案会带来许多副作用，如果您要走这条路，那么我将设计一个有效的解决方案（至少在过渡期间），并且忘记所有的首字母缩略词。你有没有考虑过建立一个响应性强的网站？这将为您提供一个适用于台式机、手机和平板电脑的解决方案。您好，我们已经有了一个适用于所有设备的网站。十分