问题标签 [anemic-domain-model]

因此，在我的 python django 应用程序中，体系结构的结构使其分为不同的应用程序。一个应用程序users，一个应用程序finance，等等。

每个应用程序都具有以下基本结构：

我正在开发一项新功能来支持促销代码。促销代码将允许用户为其即将到来的账单获得折扣。所以我创建了一个PromoCodeModel和一个PromoCodeService。在服务内部，我需要检查用户是否有资格兑换此代码。看起来这个逻辑可能会变得相当复杂，我希望将资格检查封装到它自己的类中——比如PromoCodeEligibility(user, promo_code).

我想知道——这应该属于哪里？我应该创建一个新的PromoCodeEligibilityService吗？或者我应该创建一个名为的新文件夹domain并将其设为域对象？我也可以将这个逻辑转移到model它本身，但是拥有真正胖的模型对我来说似乎更像是一种反模式。想法？

我正在编写一个 Web 服务，它有几个 API 可以从数据存储中获取数据。高级视图看起来像这样

在考虑如何在服务中设计代码时，我一直在选择正确的设计模式

我有以下几层

服务完成的唯一“工作”是在发送响应之前验证输入并从数据存储读取并将域模型转换为传输模型。我可以让服务层直接使用 dao 并发送响应。但我想知道哪种设计模式适合用例。在我看来，这也像是一个贫血域，其中域对象只是一个没有业务逻辑的 pojo。但是除了验证来自商店的数据是否对模型中的字段有效之外，没有其他业务逻辑。感谢您能告诉我处理这种情况的公认/常用方法。

问题来自 Fowler 的企业应用程序架构模式。

我努力增强公式 = dxr + c

• d 数字域定义（类）
• r 定义的复制
• c 复杂度常数

但是很难证明表格模块模式呈指数增长是合理的，因为该部分没有太多的定义复制。

为什么表模块的增强力度呈指数级增长？

参考

• 预订 http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420

• 领域模型 http://martinfowler.com/eaaCatalog/domainModel.html

• 表模块 http://martinfowler.com/eaaCatalog/tableModule.html

我最近发现，对于某些应用程序（即涉及复杂业务逻辑而不是通过 UI 公开的简单 CRUD 操作的应用程序），域驱动设计 (DDD) 是更好的选择。

我浏览了以下有关域驱动设计 (DDD) 的网站。

https://www.infoq.com/articles/ddd-in-practice

领域驱动设计：领域服务、应用服务

我无法得出结论/理解的是以下几点：

(1) 服务在领域驱动设计 (DDD) 中的作用是什么？你能用一个示例服务、域对象、DAO（使用 Java）来解释吗？

(2) 如果我需要使用 Java 创建域/业务对象，那么要遵循的命名约定是什么？是不是像 CustomerBO、ProductBO 等？

你能帮我用Java的简单例子吗？

我不喜欢下面给出的示例（在答案中），因为域对象除了携带数据之外没有做任何事情，这仍然是一个贫血模型。任何人都可以通过在域对象中进行一些行为来帮助我举一个明确的例子吗？

我正在从事一个具有复杂业务的项目。考虑两个类：AccountService 和 SchoolService

我正在使用 Unity 和 Web API 的依赖解析器在构造函数中实现依赖注入。

学校服务在某些方面使用账户服务，也有账户服务使用学校服务。所有这些都是项目业务所必需的。这将导致循环依赖，并且不可能将方法从一个类移动到另一个类。

您能否提供有关如何解决此问题的任何想法？

这是一个例子：

两个类相互引用，这是项目中 70% 的 BLC 的情况。

我知道 DDD 非常适合基于任务的 UI，但我正在重构一个遗留应用程序，其中我有贫血域模型（许多设置器没有业务逻辑）。

第一步是让它到达模型并添加领域事件。虽然添加用于创建（TaskCreated在构造函数中）和删除（TaskRemoved）模型的事件是一个简单的过程，但我正在努力更新模型。

我们有一个带有 PUT/tasks/{id}端点的 RESTful API。在底层，框架将响应的主体映射到 DTO 对象，然后一一调用 setter：

我想在任务更新时收听一些事件，并在例如谷歌日历中更新它。正如您所想象的那样，如果我在每个setter（TextChanged、StartDateChanged）中记录事件并监听所有事件，我最终会收到许多对 Google API 的 API 调用，这不是我想要的。

问题是：我应该如何以正确的方式使用更新操作？我应该setters用一个update(newData)电话替换所有这些电话并在那里只调度一个域事件吗？更新任务后如何只对谷歌日历进行一次API 调用？

我一直在阅读 Fowler 在他的网站上描述的这个贫血的领域模型问题。

他说，按照我的理解，域模型类应该包含与其相关的业务逻辑，因为这更像是 OOP 并且具有其他一些优势。

现在我的问题：假设我使用hibernate，在这种情况下，我使用JPA 或Hibernate 注释来注释我的实体类。

按照 Fowler 的说法，这些实体类应该包含业务逻辑吗？

我之所以这样问，是因为根据 Robert Martin 的说法（他在 YouTube 上的几次谈话中说），你永远不应该把你的业务逻辑放在包含某种类型的第三方代码的类中。相反，应该将业务逻辑和业务规则与特定于技术的细节分开并加以保护。

我说他们有点矛盾是对的吗？或者我只是没有得到它？

再说一遍：根据 Fowler 的说法，我应该将业务逻辑放入实体类（如 User、Product 等）中，以防我使用 presistence 框架，包含所有那些特定于技术的注释？

我一直认为你应该尽量与第三方代码解耦，以保护自己的代码免受意外更改。

因此，在我的第一家公司工作了 10 年之后，我开始了我的第二份开发人员工作，并没有真正感觉到自己获得了高级开发人员的头衔。这是 Java 开发，但我们正在使用一个贫乏的领域模型，在我看来，该应用程序是一个巨大的难以测试的混乱。不幸的是，我现在使用的代码库完全相同，最近我接受了另一次采访，采访者将他们的 Hibernate 模型描述为轻量级并且只包含 setter getter。因此，这似乎在整个行业中很普遍。

有很多文章将贫血域模型描述为一种反模式，还有一些文章将其描述为对于简单系统来说非常好。但是我还没有看到任何使用 ADM 来充分利用大型企业系统的例子。

有没有人有这方面的经验？是否有任何最佳实践来创建包含可读且实际有价值的单元测试的松散耦合系统？我真的很想为我的工作感到自豪，但我正在失去希望。

编辑：对于提倡包含在服务中的业务逻辑的开发人员：

• 您如何限制每个服务中对其他服务的依赖？即 OrderCancelService 需要 CustomerAccountService 和 PaymentService 以及 RefundCalculatorService 和 RewardsAdjustmentService 等 这往往会导致测试中出现多个模拟对象，从而使测试过于依赖于实现

• 您如何限制每个服务方法中的参数数量？由于所有内容都需要传递并且对象不会对自己的数据进行操作，这似乎会导致非常大且令人困惑的方法签名

• 你对服务对象应用告诉，不问原则吗？我看到很多服务返回值，然后调用服务使用这些值在执行流程中做出决策。

贫血模型是没有...

“贫血域模型是使用软件域模型，其中域对象包含很少或不包含业务逻辑（验证、计算、业务规则等）。”

DTO 是没有业务逻辑的贫血模型吗？而且，再一次，一个没有业务逻辑的小对象？

基本上，我的应用程序将像 stackoverflow 一样工作，您登录并发布内容，其他人来互动。

考虑 DDD 术语，并试图避免贫血模型，我现在面临这个决定：我的User实体是否应该拥有创建任何帖子更新+删除+检索他的帖子所需的知识，或者我应该退回到我的旧模式有一个“职位业务服务”，将获得UserDTO参考，PostDTO并做所有事情？

详细信息：
-我相信我需要某种帖子服务，因为主页需要列出所有帖子，管理员用户将能够删除任何帖子...... -
理想情况下，只有User实体（以及其他继承从中）应该能够创建帖子
-我不确切知道我将如何处理授权（想想阻止垃圾邮件发送者和其他人）-
也许这应该是由触发的域服务User.CreatePost(postDTO)？