我有会话对象，它们构成了一个调度系统的基础，其中gridviews用于显示重要信息。这是为了安排员工参加会议，以及让员工查看已安排的内容。
我一直在尝试遵循DDD原则，但我很难知道从服务层传递到系统的显示区域的内容。这是因为时间表可能很大，实际上由系统的许多不同元素组成。例如。客户名称，地址，案例信息，组等，所有这些都是会议日程安排人员做出决定所必需的。
除此之外，调度程序还需要更改此计划中的值并将其传递回服务层（例如，从下拉列表中分配员工，可能更改组等）。因此，信息并非真正“只读” - 它需要与之互动。即。这不仅仅是一份报告。
我们当前的方法是从SQL填充扁平的“Schedule Object”，它是从不同域对象的一小部分构造的。这是一个非常复杂的查询。进行更改后，会将其传递回服务层，服务将检索有问题的域对象，并使用DTO中的信息在域对象上触发业务方法。
我的问题是，这是正确的做法吗？即。继续从SQL生成大型自定义对象，然后从服务层传递到与View Models非常相似的表示层对象？
由于答案更新
了解所涉及的实体/聚合关系的数量。 （这是一个混淆的例子，因此关系是重要的事情）
客户端位于一个默认组
客户有一个打开案例，但很多已关闭
案例有很多会议
会议有许多已分配的员工
会议有很多原因
会议可以安排到不同的小组
员工可以与许多团体建立联系。
计划需要在属于与员工处于同一组的患者的开放案例中加载所有会议。
计划程序可以查看客户端名称，客户端地址，案例信息，MeetingTime，MeetingType，MeetingReasons，scheduledGroup（s）（showstrail），已分配的员工（也有隐藏的员工ID）。
可编辑字段分配员工下拉列表和预定组。
所以，我想要更新，是否正在使用一个查询来填充一个包含上述所有可接受的对象作为一个合并的DTO传递？如果没有，你会怎么做？ （给出一些示例调用服务层，并解释一下你如何设想ORM获取数据时记住性能）
答案 0 :(得分：0)
在服务层及以下，我会将每个实体（请参阅DDD中的聚合根）视为与事务边界分开。即即使您可以在同一UI视图中更新客户端和案例，最好以事务方式修改客户端，然后修改案例。您尝试在一个事务中修改的次数越多，就越能与其他用户发生冲突。
虽然您的日程安排很大且可以包含大量对象，但服务层应该再次单独处理每个实体（聚合根），然后将它们捆绑到一个新的视图模型中。遗憾的是，在棕色字段项目中，SQL中可能存在许多逻辑，并且大量的多表连接可能会使得更难以重构为更符合所需要的原子查询。以数据为中心的老式视图“尽你所能在数据库中”违背了所有DDD。
因为DDD是设计思想和模式的集合，而不是特别是方法或架构，所以听起来可能为时已晚，无法尝试将当前的应用程序转换为以DDD应用程序为中心的设计。听起来好像您当前的应用程序在以数据为中心的视图中非常根深蒂固。
如果当前所有内容都通过一个整体块中的层传递，那么最好保持这种风格并将这些整体块暴露给另一个团队中希望使用它们的人，以便在他们的新的应用程序您可以将某种视图模型缓存放在适当的位置（有点像CQRS中的缓存视图模型元素）。
在我个人看来，以数据为中心，规范化的数据应用程序已经过时（在20世纪70年代，当硬盘空间昂贵时，它们才有意义）并且所有应用程序都应该朝着更现代化的方式发展。实际上，只有遗留系统跪在地上时，利益相关者才会通过现金来寻找替代方案（通常是在每个服务器填充RAM之后）。可能或最好说服他们一次重构小部分。