问题标签 [domain-model]

在域模型上的 DDD 设置器的上下文中是代码异味。应该避免使用它们，原因很简单，因为它们实际上并不是域的一部分。其中没有领域专家可以理解的名词，而对数据的更改应该通过特定的方法。

例子：

虽然这样做的正确方法是拥有一种customer.ChangeAddress可以发布事件等的方法。至少根据我的理解，这都是合理的理论，我完全可以理解为什么领域模型中的设置器并不是真正可取的。

但是：如果您的域模型上没有设置器，这些方法很难测试。

如果我不能构造一个没有接受所有参数的大屁股构造函数或做一些反射魔法的客户实例，我如何让一个客户实例运行我的测试？我在后端使用 NHibernate，所以 NHibernate 已经做了一些反射魔法来填充这些字段。

但是拥有一个有 10 个参数的 ctor 感觉真的很糟糕。（对于工厂方法也是如此）。

对此有何建议？

问候丹尼尔

域模型和数据模型有什么区别？

我有一个Client对象，其中包含一个Person对象或Organization对象。这些Person对象或Organization对象可能与独立于Client对象的其他对象有关系。在这种情况下，我应该在Client对象是整体之间Client -> Person以及Client -> Organization在哪里使用 General Aggregation 关联。

还要注意这些场景：

1. 在某些情况下，人可能是普通人，例如；个人代表客户付款（*组织*）
2. 人可能是从我们这里购买产品的客户。
3. 人可能是供应商

我正在尝试将 POCO 映射为多对多关系。我不想要包含 BehavioralEvents 的 Behavior 属性。我很确定多对多映射必须在两个地方，但是我不希望我的 Behavior 类上有相应的属性。

我听说您可以使用无操作访问运算符，但我不确定如何在 Fluent Nhibernate 中执行此操作。

请指教：

行为类（不引用回 BehavioralEvent）

行为事件类映射：

行为类映射：

例如：

我有一个有 10 个小部件的用户。除此之外，我还有一个管理器来管理其中的 5 个小部件。

我想检索由指定经理管理的用户小部件。因此，我在我的 WidgetMapper 中创建了一个名为 fetchUsersManagedWidgets($userId, $managerId) 的函数，该函数在数据库中查询这 5 个小部件并映射一组 Widget 对象。

我知道域对象不应该知道它们的映射器，但是我可以在 User 模型中创建一个调用 WidgetMapper 函数的函数吗？

例如

或者这是一条单行道，域对象永远不应该调用映射器函数？

我在工作中讨论了“领域模型中的继承使开发人员的生活变得复杂”。我是一名 OO 程序员，所以我开始寻找在域模型中继承将简化开发人员生活而不是到处进行切换的论点。

我想看到的是：

另一位同事说的是：

我如何说服他（链接是WELCOME）类层次结构比在这种情况下拥有 enum 属性更好？

谢谢！

我们正在开发一个新项目（重写现有应用程序），并且我的域模型/存储库设计遇到了问题。

这是我们领域模型中两个关键部分的（简化）版本：

如您所见，我有一个Post的抽象概念，可以是评论、讨论、照片、视频等。帖子也可以有评论。

我还有一个Location的抽象概念，显然是 Streets、Cities、Neighbourhoods 等。

现在，这在我看来自然是两个清晰的总根。

所以我创建了两个存储库，一个名为PostRepository，另一个名为LocationRepository。

这一切正常，我可以添加/获取任何类型的帖子（或评论），并通过这两个存储库之一添加/获取任何类型的位置。

但是现在我处于一个城市的“登陆页面”的场景中（例如）。

在此页面上，我基本上需要显示“此位置的所有帖子”。

那是怎么定义的？好吧，可以（可选地）在某个位置标记帖子。实现细节，所以我不想深入研究数据（因为这不是 DDD 的内容），但本质上是地理空间智能可以通过位置的形状文件来确定特定位置包含哪些帖子，以及标记的帖子的纬度/经度。

但是我怎样才能在不跨越边界的情况下检索这些信息呢？

我使用哪个存储库？我需要一个新的吗？

如果它很重要（或出于好奇），这是一个带有 SQL Server 2008 数据库和 Entity Framework 4.0 的 Web 应用程序 (ASP.NET MVC)。

如果您需要任何澄清，请告诉我。

编辑

我们目前使用规范模式的修改版本来检索域模型。

例如，这是我们 BLL 中用于检索所有评分 >= 4 的评论的代码：

但现在我需要一些这样的代码：

问题是我不知道如何在不添加中间连接实体（LocationPost - 因为它是多对多的）的情况下执行上述查询，并将 FK 添加到 Post 域模型。

但是通过这样做，我跨越了总体界限——不是吗？

当我为一个领域设计模型时，它们几乎总是最终具有一些.IsSomething功能。 IsNew并且IsDirty对于数据持久性目的，IsValid业务规则验证，甚至IsFraudulent在当前项目（更多业务规则验证）等方面都很常见。每当我看到其他人实现这些时，它们几乎总是作为方法来完成。但我发现自己想知道是否有特定的原因。

我倾向于将属性视为描述对象，将方法视为执行某种操作。这些并没有真正执行操作。它们涉及代码，因为它们在调用时是动态确定的，而且它们显然是只读的，但对我来说，它们仍然适合作为属性而不是方法。

我想，属性可能存在序列化问题。尽管富域模型由于包含逻辑和功能而往往不能很好地序列化，但每当我需要跨服务边界移动某些东西时，我通常首先将其扁平化为定义的 DTO 结构。

但我想知道是否有人对这个主题有任何见解？是否有充分的理由将这些实现为方法而不是属性？

（切线相关，虽然已经给出了答案，但扩展属性确实有助于保持这样的一致性。我有许多IsSomething()扩展方法，通常是 on System.String，用于实现特定于域的逻辑。但即使属性是去吧，我可能想坚持使用方法只是为了与扩展保持一致。）

最近一直在看一些 Greg Young 的视频，我试图理解为什么对域对象上的 Setter 持消极态度。我认为域对象应该是 DDD 中的“重”逻辑。网上有没有关于坏例子的好例子，然后他们有办法纠正它？任何例子或解释都是好的。这仅适用于以 CQRS 方式存储的事件还是适用于所有 DDD？

问题：

对于 asp.net mvc 应用程序，我忽略了域文件夹并将域模型写入单独的库项目中。

具有此类库项目的 Visual Studio 将逐个文件夹命名空间。例如，如果我的库项目被调用：

ES.eLearning.Domain

我有一个名为 Services 的文件夹，它会将 Services 文件夹中的所有类自动命名为：

ES.eLearning.Domain.Services

这一切都很好，但让我觉得矫枉过正。我的项目相对简单，所以没有类名冲突的可能性。即使有，编译器也会选择它。

所以我只是手动将命名空间名称编辑为项目名称，即：

ES.eLearning.Domain

这样，在开发前端时，域模型项目只是一个黑匣子，它提供了一个域模型。而且我没有看到将命名空间名称耦合到项目文件夹结构的意义，而不是将其视为一个功能块。

于是出现了两个问题：

1. 这是不好的做法吗？如果是这样，为什么？请记住：这些都是中小型项目。

2. 有没有办法告诉 VS 2010 如何命名我的命名空间？

谢谢

注意：在我对项目的命名中，ES 是客户端，eLearning 是应用程序，Domain 是组件

PS：我在 SO 上找到的关于命名空间命名约定的其他问题解决了不同的问题。因此，据我所知，不是重复的。