代码之家 › 专栏 › 技术社区 › n8wrl

这真的是DDD吗?

domain-driven-design

n8wrl · 技术社区 · 16 年前

我百分之八十肯定我不应该问这个问题,因为它可能会被认为是消极的,我的意思是不尊重任何人,尤其是这本书的作者。我看过几篇推荐这个的文章 book 和它的同伴 project .我没有读这本书,但我今天花了几个小时研究这个项目。虽然它看起来很完整,但我很难理解各种细节的分散程度。我在自己的设计中挣扎,如果一个实体改变了,我需要改变多少,而这个项目并不能让我很舒服地成为一个解决方案。

例如,有一个Employee对象继承自一个人。人有一个具有名字、姓氏等的构造函数,因此雇员也有。private-to-employee是名字、姓氏和公共属性的成员。

有一个EmployeeFactory既知道Employee属性又知道Person属性,还知道SQL列名(从读卡器中提取值)。

有一个EmployeeRepository具有未实现的PersisteNewItem和PersisteUpdatedItem方法,如果实现了这些方法,我怀疑它们会为insert和update语句构建SQL,就像我在CompanyRepository中看到的那样。它们将属性写入字符串以生成SQL。

存在一个“数据合同”人员合同,该合同与人员具有相同的私有成员和公共财产,以及一个从人员合同继承的EmployeeContract,就像Employee Do Person一样,公共财产与实体相镜像。

有一个静态的“converter”类,其中包含将实体映射到协定的静态方法,包括

EmployeeContract ToEmployeeContract(Employee employee)

它将字段从一个复制到另一个,包括个人字段。可能有另一种伴生方法——不确定。

我想也有单元测试。

在所有的例子中,我计算了5-10个类、方法和构造器,这些类、方法和构造器对实体属性有详细的了解。也许它们是自动生成的-不确定。如果我需要向Person添加“称谓”或其他属性,我将不得不调整所有这些类/方法?我肯定我会忘了什么。

再说一次,我的意思是没有不尊重,这似乎是一个非常彻底,详细的例子,这本书。DDD就是这样做的吗?

3 回复 | 直到 15 年前

Charlie Martin 16 年前

DDD足够新(至少在某种意义上是这样),所以说“它是如何完成的”可能还为时过早。尽管我们没有给它起一个很酷的名字,但这个想法已经存在了很长一段时间了。

在任何情况下,简短的回答(imao)都是“是的,但是……”进行域驱动设计的想法是非常明确地建模域。你看到的是一个领域模型,也就是说一个面向对象的模型,它用问题领域的语言描述问题领域。其思想是,一个领域模型,因为它是“真实世界”的模型,对变化相对不敏感,而且也倾向于局部化变化。因此,例如,如果您对员工的想法发生了变化,可能是通过添加邮件地址和物理地址,那么这些变化将相对本地化。

但是,一旦您拥有了这个模型,您就拥有了我所维护的体系结构决策。例如,您有一个未实现的持久性层,它实际上可能只是SQL的构造。它也可以是一个休眠层,或者使用python pickle,或者甚至是像google-appengine分布式表结构这样的疯狂的东西。

问题是,这些决策是单独做出的,并且与其他的基础理论相比较,而不是域建模决策。

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

RibaldEddie 16 年前

领域驱动的设计非常简单。它说:让你的模型类反映真实世界。因此,如果您有员工,那么就有一个员工类,并确保它包含赋予它“员工素质”的属性。

您要问的问题不是关于DDD,而是关于一般的类体系结构。我认为你对一些关于你正在看的课程的决定提出质疑是正确的,但这与DDD无关。一般来说,它与OOP编程设计模式更相关。

Steven A. Lowe 15 年前

对我来说,DDD不同于“纯粹”的模型驱动设计的是“聚合根”的概念,即应用程序是 只允许保留对聚合根的引用 ,一般来说,您只有一个聚合根类的存储库,而不是聚合根使用的类。

这将极大地清理代码;另一种方法是存储每个模型类,它只是一个分层设计,而不是DDD