域驱动设计 – 这是真的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中进行域模型，然后用它构建一个模拟器，而不是实现最终的系统。这使得客户可以尝试的东西，也可能允许您对最终实现必须确定的事情进行定量估计。