oop – DDD – 持久化模型和领域模型

前端之家收集整理的这篇文章主要介绍了oop – DDD – 持久化模型和领域模型前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我试图学习域驱动设计,我想我有基本的想法。但有一些让我困惑。

在DDD中,是持久性模型和领域模型不同的东西吗?我的意思是,我们设计的领域和类只考虑域的关注,没关系。但是之后,当我们建立我们的存储库或任何其他数据持久化系统,我们应该创建我们的模型的另一种表示,以在持久层中使用?

我认为我们的域模型也用于持久性,这意味着我们的存储库从查询返回我们的域对象。但今天,我读这篇文章,我有点困惑。

http://www.sapiensworks.com/blog/post/2012/04/07/Just-Stop-It!-The-Domain-Model-Is-Not-The-Persistence-Model.aspx

如果这是真的从域对象有独立的持久化对象的优势是什么?
感谢任何帮助…

只要这样想,域模型应该依赖什么,没有基础设施代码。域模型不应该是可序列化的,或者继承自某些ORM对象,甚至不能共享它们。这些都是基础设施问题,应该与域模型分开定义。

但是,这是如果你正在寻找纯DDD和你的项目值可扩展性和性能超过初始开发的速度。很多时候,将基础设施问题与您的“域模型”混合可以帮助您以可扩展性为代价,在速度上取得巨大进步。关键是,你需要问自己:“纯DDD的好处是否值得在开发速度上的成本?如果你的答案是肯定的,那么这里是你的问题的答案。

让我们从一个例子开始,你的应用程序开始与域模型,只是这样发生,数据库中的表匹配您的域模型。现在,您的应用程序会根据跳跃和边界增长,并且在查询数据库时开始遇到性能问题。你已经应用了一些精心设计的索引,但是你的表增长如此之快,它看起来像你可能需要反标准化你的数据库只是为了跟上。所以,在dba的帮助下,你想出了一个新的数据库设计,将处理你的性能需求,但现在的表与以前的方式有很大的不同,现在块的实体分布在多个表,而不是而不是每个实体的一个表。

这只是一个例子,但它演示了为什么你的域模型应该与持久性模型分开。在本示例中,您不想分拆域模型的类以匹配对持久性模型设计所做的更改,并且实质上更改域模型的含义。相反,您要更改新的持久性模型和域模型之间的映射。

保持这些设计分离有几个好处,例如可扩展性,性能和对紧急数据库更改的反应时间,但是您应该根据初始开发的成本和速度进行权衡。一般来说,将从这种分离水平中获益最大的项目是大型企业应用程序。

更新评论

在软件开发的世界中,存在第N个可能的解决方案。因此,在灵活性和初始发展速度之间存在间接的反比关系。作为一个简单的例子,我可以硬编码逻辑到类中,或者我可以编写一个类,允许动态逻辑规则传递到它。前一种选择方案将具有较高的发展速度,但是以较低程度的灵活性为代价。后一种选择将具有较高程度的灵活性,但代价是较低的发展速度。这在每种编码语言中都成立,因为总是存在N个可能的解。

许多工具可用于帮助您提高初始开发速度和灵活性。例如,ORM工具可以提高数据库访问代码的开发速度,同时还可以灵活地选择ORM支持的特定数据库实现。从你的角度来看,这是时间和灵活性的净收益减去工具的成本(其中一些是免费的),这可能是或不可能是值得的,基于开发时间的成本相对于业务需要。

但是,对于这种编码风格的交谈,这本质上是域驱动设计,你必须考虑到你使用它编写的工具花费的时间。如果你写的是ORM工具,或者甚至编写你的数据库访问逻辑,它支持所有的工具给你的实现,这将需要比如果你只是硬编码的具体实现你计划使用。

总之,工具可以帮助您抵消自己的生产时间和灵活性的价格,通常通过将该时间的成本分配给购买该工具的每个人。但是,包括使用工具的代码的任何代码将仍然受速度/灵活性关系的影响。以这种方式,域驱动设计允许更大的灵活性,比如果你纠缠的业务逻辑,数据库访问,服务访问和UI代码在一起,但是以生产的时间为代价。域驱动设计为企业级应用程序提供优于小型应用程序的优势,因为企业级应用程序往往在初始开发时间方面具有较高的成本,因为它们更复杂,它们也更容易发生变化,需要更大的灵活性降低成本。

原文链接:https://www.f2er.com/javaschema/282345.html

猜你在找的设计模式相关文章