For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
我们在前几期的文章中给大家简单介绍了领域驱动设计技术的一些基础知识以及用法等内容,而本文我们就继续来学习一下,领域驱动设计都有哪些设计原则。
1、数据库提供者/ORM无关性
领域和应用程序层应该与ORM/数据库提供程序无关。它们应该只依赖于Repository接口,而Repository接口不使用任何ORM特定的对象
为了使您的领域/应用程序独立于基础设施,因为基础设施可能在将来更改,或者您可能需要支持另一种数据库类型
通过将基础设施细节隐藏在存储库后面,使您的领域/应用程序专注于业务代码。
使您的自动化测试更容易,因为在这种情况下您可以模拟存储库
根据这一原则,解决方案中的任何项目都没有引用EntityFrameworkCore项目,除了启动应用程序
2、关于数据库无关性原则的探讨
上述原因1,深深地影响了你的领域对象设计(尤其是实体关系)和应用程序代码。假设您正在使用EFCore与关系数据库。如果你想让你的应用在以后切换到MongoDB,你就不能使用一些非常有用的EFCore特性
例如:
你不能假设ChangeTracking,因为MongoDB不能这样做。因此,您总是需要显式地更新已更改的实体。
您不能对实体中的其他聚合使用导航属性(或集合),因为这对于文档数据库是不可能的。
如果你认为这些功能对你很重要,并且你永远不会偏离EFCore,我们相信这一原则是值得延伸的。我们仍然建议使用Repository模式来隐藏基础设施细节。但你可以假设你在设计实体关系和编写应用程序代码时使用的是EFCore。你甚至可以从你的应用层引用EFCore的NuGet包来直接使用异步LINQ扩展方法,比如ToListAsync()
3、表现层技术无关性
表现层技术(UI框架)是真实应用程序中变化大的部分之一。在设计领域层和应用层时,完全不考虑表现层技术/框架是非常重要的。这一原则相对容易实现,而ABP的启动模板使之更加容易
在某些情况下,您可能需要在应用程序层和表示层中有重复的逻辑。例如,您可能需要在两个层中重复验证和授权检查。UI层中的检查主要是为了用户体验,而应用程序层和领域层中的检查是为了安全性和数据完整性。
4、关注状态变化,而不是报告
DDD关注领域对象如何变化和交互;如何创建实体并通过保持数据完整性/有效性和实现业务规则来更改其属性
DDD忽略报告和大规模查询。这并不意味着它们不重要。如果您的应用程序没有花哨的仪表板和报告,谁会使用它呢?然而,报告是另一个主题。您通常希望使用SQLServer的全部功能,甚至使用单独的数据源(如ElasticSearch)来进行报告。您将编写优化的查询、创建索引甚至存储过程(!)。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。