域驱动设计 – 这是真的DDD吗?

前端之家收集整理的这篇文章主要介绍了域驱动设计 – 这是真的DDD吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有80%的确我不应该问这个问题,因为它可能会是负面的,我的意思是不尊重任何人,特别是这本书的作者。我看过几个帖子推荐这个 book及其伴侣 project.我没有看过这本书,但是我已经花了几个小时学习这个项目。虽然它看起来很完整,但我非常难过,各种细节的细节分散在多少。我在自己的设计中努力奋斗,如果一个实体发生变化,我必须改变多少,而这个项目并不能使我非常舒适,因为它是一个解决方案。

例如,有一个从Person继承的Employee对象。 Person拥有名字,姓氏等构造函数,因此Employee也是如此。私人雇员是名字,姓氏,加上公共属性的成员。

有一个EmployeeFactory了解Employee和Person属性以及sql名称(从读取器中提取值)。

有一个没有实现的PersistNewItem和PersistUpdatedItem方法的EmployeeRepository,我怀疑,如果实现,将为INSERT和UPDATE语句构建sql,如我在CompanyRepository中看到的那样。这些将属性写入字符串以构建sql

有一个“数据契约”PersonContract具有与Person相同的私有成员和公共属性,以及从PersonContract继承的EmployeeContract,如Employee Person,具有镜像实体的公共属性

有一个静态的“转换器”类,具有将实体映射到合同的静态方法包括

EmployeeContract ToEmployeeContract(Employee employee)

它们将字段从一个复制到另一个,包括Person字段。可能有一种伴随的方法,而另一种方式 – 不确定。

我认为也有单位测试。

在所有我计数5-10个类,方法和构造函数具有关于实体属性的详细知识。也许他们是自动生成的 – 不确定。如果我需要向Person添加一个“称呼”或其他属性,我将不得不调整所有这些类/方法?我确定我会忘记一些东西。

再次,我的意思是不尊重,这似乎是这本书的一个非常彻底,详细的例子。 DDD是如何完成的?

DDD足够新(至少在某种意义上),说出“如何做好”可能有点早。这个想法一直在很长一段时间,虽然我们没有为它做一个很好的名字。

无论如何,简单的答案(IMAO)是“是的,但是….”做一个域驱动设计的想法是非常明确地对域进行建模。你所看到的是一个域模型,也就是说一个面向对象的模型,用来描述问题域语言中的问题域。这个想法是,一个域模型,因为它模拟“现实世界”,对变化相对不太敏感,也倾向于本地化变化。所以,如果你的想法是雇员改变什么,也许通过添加一个邮寄地址和一个物理地址,那么这些改变就会相对本地化。

一旦你有了这个模型,那么你所拥有的就是建筑的决定。例如,您有未实现的持久层,这可能是简单的sql构造。它也可以是一个Hibernate层,或者使用Python酸洗,甚至是像Google AppEngine分布式表结构一样野蛮的东西。

事实是,这些决定是单独制定的,并且与其他理由相比,而不是域建模决策。

我尝试过的一些好的结果是在Python中进行域模型,然后用它构建一个模拟器,而不是实现最终的系统。这使得客户可以尝试的东西,也可能允许您对最终实现必须确定的事情进行定量估计。

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

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