我80％肯定我不应该问这个问题，因为它可能会被认为是消极的，我的意思是不会对任何人不尊重，特别是本书的作者。我看过几篇帖子推荐这个book及其同伴project。我没看过这本书，但今天我花了几个小时研究这个项目。虽然看起来非常完整，但我很难分清各种各样的细节。我在自己的设计中苦苦挣扎，如果一个实体发生变化，我必须改变多少，而这个项目并没有让我感到非常舒服。
例如，有一个继承自Person的Employee对象。 Person有一个带有名字，姓氏等的构造函数，因此Employee也是如此。私人雇员是名字，姓氏和公共财产的成员。
有一个EmployeeFactory知道Employee和Person属性，以及SQL列名称（从读取器中提取值）。
有一个带有未实现的PersistNewItem和PersistUpdatedItem方法的EmployeeRepository，我怀疑，如果实现的话，将为INSERT和UPDATE语句构建SQL，就像我在CompanyRepository中看到的那样。这些将属性写入字符串以构建SQL。
“数据合同”PersonContract与Person具有相同的私有成员和公共属性，而EmployeeContract继承Personcontract，如Employee，Person，公共属性镜像实体。
有一个静态'Converter'类，其中包含将实体映射到Contracts的静态方法，包括
EmployeeContract ToEmployeeContract(Employee employee)
将字段从一个复制到另一个，包括Person字段。可能有另一种方式的伴侣方法 - 不确定。
我认为也有单元测试。
总而言之，我计算了5-10个具有关于实体属性的详细知识的类，方法和构造函数。也许他们是自动生成的 - 不确定。如果我需要向Person添加“Salutation”或其他属性，我将不得不调整所有这些类/方法？我确定我会忘记一些事情。
同样，我的意思是没有不尊重，这似乎是本书的一个非常详尽的例子。这是DDD的完成方式吗？
答案 0 :(得分：14)
Domain Driven Design非常简单。它说：让你的模型类镜像现实世界。因此，如果您有Employees，请拥有一个Employee类，并确保它包含为其提供“Employee-ness”的属性。
你问的问题不是关于DDD，而是关于一般的类架构。我认为你对正在考虑的课程的一些决定提出质疑是正确的，但它与DDD无关。它通常与OOP编程设计模式有关。
答案 1 :(得分：10)
DDD足够新（至少从某种意义上说）说到“如何完成”可能还为时过早。尽管如此，这个想法已经存在了很长一段时间，虽然我们并没有为它做出一个很酷的名字。
在任何情况下，简答题（IMAO）都是“是的，但是......”进行域驱动设计的想法是非常明确地对域进行建模。你正在看的是一个域模型，也就是说一个面向对象的模型，用于描述问题域语言中的问题域。这个想法是，域模型，因为它模拟“现实世界”，对变化相对不敏感，也倾向于本地化变化。因此，如果您对Employee的内容有所改变，可能是通过添加邮件地址和物理地址，那么这些更改将相对本地化。
一旦你拥有了那个模型，你拥有的东西仍然是建筑决策。例如，您有未实现的持久层，这可能只是SQL的构造。它也可以是一个Hibernate层，或者使用Python pickling，甚至可以像Google AppEngine分布式表结构一样疯狂。
问题是，这些决策是与域建模决策分开制定的，并与其他理由一起制定。
我尝试过一些好的结果是在Python中使用域模型然后用它构建模拟器而不是实现最终系统。这使得客户可以尝试一些东西，并且还可能允许您对最终实施必须确定的事项进行定量估计。
答案 2 :(得分：8)
这大大清理了代码;替代方案是每个模型类的存储库，它“仅仅”是一个分层设计，而不是DDD