如何管理域模型或数据访问模型或数据传输模型

Question

在DDD中,有许多模型:

• 域模型,用于业务或应用层.
• 数据访问模型,用于数据访问或数据存储库层.
• 数据传输模型(DTO),用于表示层.

由于他们,缺点提出:

• 它们违反了DRY原则,因为它们之间存在许多重复的字段而无法避免.
• 他们需要对不同层之间的转换进行大量烦躁的映射.

我们怎样才能减少烦躁的模特？

Answer 1

最终,它是关于选择你的战斗.域驱动解决方案的主要考虑因素之一是它专注于域的隔离和封装.这意味着,在这个前提下,您不会希望将其用作每个项目中的方法.您需要具有您尝试减少的固有复杂性,并且您可以通过独立地模拟业务需求和应用程序需求来实现这一点.这意味着您不是在创建单个系统,而是创建一个或多个使用完善子系统(您的域)的系统(您的应用程序或应用程序).

就个人而言,我没有您在我的任何项目中描述的三种类型的数据承载类.相反,我只有我的域模型和基于每个不同UI要求的视图模型表示.我发现需要一组单独的持久化类是多余的.有几种方法可以消除对持久性类的需求,例如具有代码优先EF的POCO,对象数据库/ NoSQL,以及读取模型和写入模型的分离.在大多数情况下,我个人选择最后两个的组合.

域和应用程序/ UI之间的转换层是我发现需要的东西,因为域所代表的"真实性"是绝对可靠的.但是,为了获得域中的可用接口,应用程序有时会对域具有额外的或不同的要求.这意味着这个转换层不仅仅是关于字段映射,而是关于不同概念的封装和使用场景的隔离.

由于域应该完全不知道如何使用它,这意味着需要进行转换,并且不应该尝试从系统中解决.我见过的人直接在UI中使用他们的域类作为实际模型,这比创建翻译层更令人发指(在我看来).你只是从翻译的角度看待它,但要记住它也是关于隔离的.在翻译中可以有效地拦截新概念的引入,现有概念的更改以及域内的其他更改,以防止在UI中产生影响,反之亦然.

这听起来微不足道,但在企业环境中,不仅仅有一个应用程序利用域,而是多个应用程序并不罕见.考虑您的域服务于桌面应用程序,Web应用程序和REST API的可能性.其中每个都有自己的特定应用程序要求,这些要求与业务要求分开.他们也可能希望以不同方式表示域名.这意味着它们中的每一个都可能具有不同的验证要求,对您的域的不同视图以及独特的应用程序功能.无论如何,域名仍然高兴地忘记了这一切.您必须针对每个域进行不同的翻译.

如果您发现您的模型看起来与您的域完全一样,并且大部分是一对一映射,那么您可能需要退一步寻找可能正在发生的其他一些问题.我发现大量的奇异字段的双向映射是代码气味.并非总是如此,但通常情况下,这是贫血领域模型的早期迹象.我个人甚至在我的域模型上强制执行体系结构要求,例如要求属性是只读的(强制它们通过现有数据的构造函数设置并通过类上的方法进行更改)等.这是公平的.编写体系结构单元测试的简单方法,它将反映您的域类,以检查它们是否存在违反此类规则的行为.但是,关键是如果您发现翻译是您的痛点,请确保您的域模型不仅仅是作为数据容器.贫困领域模型在DDD实施中是一个非常常见的陷阱,并且对于贫困领域模型,DDD方法实际上几乎没有什么好处,因为您将权力和责任从应该执行的地方带走.

业务需求应该反映域的需求,这与域的使用模式不同.理想情况下,您应该告诉域您希望如何更改其状态,域应该应用域逻辑来允许或禁止这些更改.如果您发现自己为域的一部分提取完整的域模型表示,将整个事物转换为模型或DTO,修改该模型或DTO,将其转换回域表示,然后将整个事物发送回去,你可能有一个更大的问题.