问题标签 [domain-model]

我对 Grails 很陌生，所以我希望我有一个简单的问题要问你。

我有一个 DomainModel ，这个模型里面是一个相关的模型（一对多）。假设服务和服务作为“n”个任务。我选择（通过 findAllBy()），例如 3 个服务，例如，每个服务至少有一个或三个任务。

现在我的问题。我不想返回“将 foundServices 渲染为 JSON”。原因：我不想让全世界的人知道我的模型定义和一些可能是“秘密”的属性，这些都是由数据库返回/选择自动填充的。这是一个正确的想法，还是“太多太深的安全感”？

所以我试图找出如何以与这些对象类似的方式返回我需要的相关数据。

我试过：

1）这是太多的“开销”吗？

2）你认为“好的没关系，返回整个DomainModel（来自搜索结果）”

3）如果我将自己的“数组列表”放在一起，如何做到类似于域模型以轻松访问每个服务中的所有属性和“n”任务列表

非常感谢你！

我一直在阅读“SQL Antipatterns: Avoiding the Pitfalls of Database Programming”一书，尤其是关于魔术豆反模式的书。在它显示了一个使用域模型解耦活动记录的图表，并在 PHP 中有示例，但在 Rails 中没有，它将此称为域模型和视图/控制器之间的 HAS-A 聚合以及域模型和活动记录之间的 HAS-A 组合（I假设这是 UML 语言）。

在 Rails 中，使用模型方法使瘦控制器变成胖模型似乎很常见，这些方法可以操作其他关联的模型，以便在任何给定的控制器中只能使用一个模型。但是，我想知道在 Rails 中是否有一种包括完全解耦的做法？

也就是说，创建一个无表模型或其他类用作域模型，充当控制器和活动记录对象之间的层（这些对象又映射到表），以便控制器具有更好的隔离性并且不需要知道任何东西关于底层数据库及其结构。它还提供了摆脱不解释它们应用的应用程序要求的 CRUD 方法的选项，这是书中的另一个批评。

我正在寻找一些关于我应该在多大程度上关注避免贫血域模型的建议。我们刚刚开始使用 DDD，并且正在与简单设计决策的分析瘫痪作斗争。我们坚持的最新一点是某些业务逻辑所属的地方，例如我们有一个Order对象，它具有诸如此类的属性Status。现在说我必须执行一个命令，例如UndoLastStatus因为有人在订单上犯了错误，这不是那么简单就像Status必须记录其他信息并更改属性一样更改。现在在现实世界中，这是一项纯粹的管理任务。所以我看到它的方式有两个我能想到的选择：

• 选项 1：将方法添加到 order 这样的东西Order.UndoLastStatus()，虽然这有点道理，但它并不能真正反映域。也是Order系统中的主要对象，如果涉及订单的所有内容都放在订单类中，事情可能会失控。

• 选项 2：创建一个Shop对象，该对象具有代表不同角色的不同服务。所以我可能有Shop.AdminService,Shop.DispatchService和Shop.InventoryService. 所以在这种情况下，我会有Shop.AdminService.UndoLastStatus(Order).

现在第二个选项我们有了更多反映领域的东西，并且允许开发人员与业务专家讨论实际存在的类似角色。但它也走向了贫血模型。一般来说，哪种方式更好？

我正在尝试使用业务方法构建域模型并让 EF 4.1 为我做持久性。到目前为止，一切都很好。

问题是，所有属性都在我的域类中公开。无论如何，这至少是我从教程中学到的。这意味着，我没有强有力的证据证明类属性不会被业务方法之外的一些粗心的程序员改变。违反封装。

我尝试引入 ISomething 但 TableAttribute 仅适用于类，不适用于接口，所以我不能告诉 EF 做 DBSet。如果我将 TableAttribute 留给类，但无论如何都要让 Something 实现 ISomething，那么我不能执行 DBSet.Add()，因为 EF 不知道 ISomething。

我能想到的唯一方法是在 EF 4.1 之上使用接口为 CRUD 编写一个完整的抽象层。在引擎盖下，做Something 和ISomething 之间的类型转换。这听起来很复杂，而且 EF 的设计存在巨大的漏洞。或者我一定错过了什么。

你会如何解决这个问题？

非常感谢。

我正在阅读的一位通用数据模型作者认为，根据他的经验，50% 的企业系统在处理各方、工作努力等方面是“通用的”，25% 在该企业的行业中是通用的，其余的对于给定的企业来说是独一无二的（例如，可口可乐诉百事可乐）。

但是我不知道基于此构建的代码，并且无法想到有人真正从领域的角度看待模式，而不是数据建模，因为福勒在 90 年代中期就这样做了。

是否有任何具有 DDD 方向的人对通用数据模型的有用性有任何基于意见的经验？

你真的有子类型的派对仅限于个人和组织，其他人都在角色中吗？如果是这样，你如何实施？

您喜欢任何实施指南或开源系统吗？

干杯，
贝里尔

假设我想发出一个更新房屋状态的发布请求，理想情况下，这些数据应该在某种服务层中，通常这涉及

1. 验证用户 - 他们仍然活跃还是被管理员踢出？
2. 检查 houseid - houseid/记录是否有效？
3. 用户可以看到房子的详细信息吗？
4. 将状态更新为“打开”或“关闭”

在现实世界/复杂领域中 - 大多数视图都非常复杂，我们必须抛出该区域的房屋数量，房屋评论数量，房屋详细信息等，也许房屋未完成任务的数量...

简而言之-上述所有代码都可能在服务层内，但是可以说抛出异常，用户无法更新房屋的状态-现在要填充视图，您必须首先（再次）获取房屋详细信息，加载将您刚刚在服务层中加载的所有其他内容所有这些都放在控制器中，或者对加载此数据的服务层进行其他创新...

如何通过运行验证和各种方式来确保我的域模型受到保护，而无需多次重写相同的代码......

此代码在操作方法内，它很容易在服务层内......

//注意：_repo 是对 linq to sql 的简单抽象...

简而言之-获取摘要的房屋详细信息，获取任务详细信息（从多个可用任务中）并获取任务评论。恕我直言，这是一个简单的观点，没什么太复杂的。

此时用户可以： 添加评论、关闭/打开任务 - 如果他们有权这样做（为简单起见省略了代码）、设置任务截止日期，甚至清除任务的截止日期。

现在UpdateTaskStatus - 如果不能更新状态必须返回上面的视图，类似于评论，如果你不能评论请返回详细视图——评论可能被关闭。

我知道上面的代码结构很糟糕，但是对于如何纠正它的一些建议将不胜感激。

1. 我将所有只读代码留在操作中，因为每个视图可能不同，我不希望服务层干扰这里
2. 我想“保护”我的更新/编辑并将其保存在我的服务层或核心项目（单独的 c# 类库）甚至域层中，我将如何编写代码处理验证，（这是我在服务中所做的调用），执行实际保存？

我听说过 CommandHandler 方法，这是一个好方法吗？理想情况下，我想在我的域中使用一种简单的方法而不是控制器操作来保持我的验证+持久性....

我正在开发一个我们尝试使用域模型的应用程序。这个想法是将业务逻辑保留在域模型中的对象内。现在，订阅相关对象以对它们的变化做出反应的对象完成了很多工作。这是通过 PropertyChanged 和 CollectionChanged 完成的。这项工作正常，但以下情况除外：

复杂操作：应将大量更改作为一个组处理（而不是单个属性/集合更改）。我应该/如何“建立”交易？

持久性：我使用 NHibernate 来实现持久性，这也使用了类的公共属性设置器。当 NHibernate 命中该属性时，会完成很多业务逻辑（这似乎没有必要）。我应该为 NHibernate 使用自定义设置器吗？

总体而言，在域模型中推动所有逻辑似乎使域模型相当复杂。有任何想法吗？？？

这是一个“示例”问题（对不起，我使用了糟糕的工具）：

您可以看到项目我的容器和它下面的对象通过订阅相互反应。现在对 Network 的更改是通过 NetworkEditor 完成的，但是这个编辑器不知道 NetworkData。有时甚至可能在另一个程序集中定义此数据。流程来自 user->NetworkEditor->Network->NetworkData 和所有其他感兴趣的对象。这似乎没有规模。

我试图弄清楚如何将域模型一般地映射到表示模型。例如，给定以下简单的对象和接口...

我希望能够编写这样的代码......

...其中“MapperObject”可以使用反射、基于约定的映射等自动确定映射两个对象的属性以及映射的对象类型。所以，我可以很容易地尝试使用相同的 MapperObject 映射 UserPresentationModel 和 User 等对象。

这可能吗？如果是这样，怎么做？

编辑：为清楚起见，这里是我当前使用的非泛型 MapperObject 的示例：

我仍在尝试解决如何使其与 List 一起使用，而不仅仅是单个产品，但这是一个不同的主题 :)

我有一个故事，可以分配一个提名人。可以将提名人分配给多个故事。提名人可以将一个故事移到他们的选票上（不是一个故事只能属于他们的提名人选票）。我过去一直在做数据驱动的应用程序，所以不幸的是我已经在考虑如何处理选票了。由于 Story 表具有分配给它的提名者 ID，因此将 IsBallot 标志添加到表中是有意义的。但现在在我的实际域设计中，故事有一种将自己添加到选票中的行为（这似乎很奇怪，因为在这方面有与提名人相关的规则）。我想它可以询问提名人是否可以将自己添加到选票中。我的第二个选择是拥有另一个包含提名者 ID 和故事 ID 的表 StoryBallot。

任何想法或建议都会很棒！

我正在从事的一个具有这种设计模式的项目，一个 bean 由 jsp/action/service 类定义和使用，即由表示层和业务逻辑层使用，而另一个 bean 由定义和使用DAO 层，称为“实体”，无论这两个 bean 的内容实际上是相同的，我被告知使用两个 bean 是 Java EE 设计模式所要求的，以解耦每个层。我对解耦的理解是通过类的工作流以及类层次结构来实现的，但是对于数据流，使用相同的 bean 是直接而流畅的，而为 DAO 层引入 POJO 的原因之一是确保这种转变是顺利的。请分享您的专业知识，通过解耦此数据流可以获得好处，以及在数据流中使用相同的 bean 会有什么缺点？