anemic-domain-model

2热度

3回答

我在审查可以优化抵押计算工具设计的领域，主要是为了学习目的。在阅读了贫血域模型之后，我开始对创建丰富模型感兴趣，并且注意到我目前的实现可能有贫血症！这里是伪代码当前实现： class MortgageCalculator { Mortgage mortgage; // mortgage object containing loanAmount, interest rate, etc.;

1热度

2回答

这是“贫血”模型可接受的设计吗？

我首先想说我是而不是试图完成我目前设计中的领域模型。话虽这么说，我目前正在建设一个类似如下的架构： UI DTO <=> Service DTO <=> Business/Database DTO (using AutoMapper) 我一直在阅读Eric Evan's DDD book，并还观看Greg Young's 7 reasons why DDD projects fail，生怕贫

0热度

1回答

使用现有（第三方）数据模型（Java）的域驱动开发

首先，我想说我的标准开发软件方法可能是很多开发人员的典型做法......我拥有丰富的行为但没有状态，我有对象（豆）只有状态和没有行为（我认为这通常被称为贫血域模型）。我已经决定在一个新项目上尝试一个域驱动设计（DDD）方法，但是我有几个问题真的让我很尴尬。我有我的组织使用（并紧密结合的业务并没有什么我可以做这个现有的第三方数据库：我不想发表任何评论提怎么这会导致问题，如果第三方改变了他们的数据

1热度

1回答

是否可以在另一个内部使用EntityRepository？

例如，考虑头版如Jobeet的教程：类CategoriesRepository延伸EntityRepository { public function getWithJobs($limit) { $categories = $this->getContainingJobs(); $jobsRepo = $this->em->getRepository("Jobeet

0热度

1回答

服务在域驱动设计中的作用

我最近发现域驱动设计（DDD）对于某些应用程序（即涉及复杂业务逻辑的应用程序而不是通过UI公开的简单CRUD操作）是更好的选择。我已经浏览了域驱动设计（DDD）的下列网站。 https://www.infoq.com/articles/ddd-in-practice Domain Driven Design: Domain Service, Application Service 我不能得出什么

0热度

1回答

如何处理使用DDD更新实体（CRUD）和域名事件？

我知道DDD在基于任务的用户界面方面很好，但我正在重构遗留应用程序，我在那里有贫血域模型（许多设置者没有业务逻辑）。其中一个步骤是使其到达模型并添加域事件。在添加事件创建（TaskCreated在构造函数中）和删除（TaskRemoved）模型是一个简单的过程，我正在努力与更新模型。我们有一个RESTful API和PUT /tasks/{id}端点。引擎盖下框架映射响应DTO对象的身体，然后

2热度

1回答

DTO贫血模型/贫血值对象？

贫血模型是一种模型，没有... “贫血域模型是使用软件域模型，其中域对象包含很少或没有业务逻辑（验证，计算，业务规则等）。” DTO是一种没有业务逻辑的贫血模型吗？而且，再一次，没有其业务逻辑的balie对象？

1热度

1回答

将域模型标记为贫血的标准是什么？

到目前为止，我还没有遇到一篇博客文章或一篇文章，其中描述了将领域模型标记为贫血症的客观标准。我认为，这肯定有助于为贫血域模型设定客观标准。几年前，我设计了一个领域模型。我在数据库中有几张表（大约7）。我在代码中创建了完全相同数量的类。我为每个类实现了存储库模式。今天，我绝对认为这是一个贫血的领域模型。我有机会设计一个面向对象的领域模型，但我设计的领域模型本质上是关系型的。根据这一经验，我定义的一

11热度

2回答

EAA中P的域模型和服务层模式

在企业应用程序体系结构的模式中，Martin Fowler讨论了组织域逻辑的两种模式：Domain Model和Service Layer。域模型模式是“纯粹的OOP”方法，其中模型（可能使用ORM从数据库中查找的那些对象）包含业务逻辑（尽管可能仅委托给另一个类中的逻辑）。服务层图案就像领域模型模式，但在含有可被执行的业务操作它的前面的薄层。在MVC中，控制器将主要与服务层进行交互。我相信大多数

1热度

1回答

应用程序架构 - User.CreatePost（Post）或PostsService.CreatePost（Post，User）？

基本上，我的应用程序将像stackoverflow一样工作，在那里你登录和发布的东西，其他人来和互动。考虑DDD条款，并试图避免贫血模型，我现在面临这样的决定：我的User实体是否拥有创建任何更新后所需的知识+删除+检索他的帖子或我应该退后到旧的模式，我有一个“职位的业务服务”，将得到一个UserDTO参考，PostDTO和做一切？详情： - 我相信，我将需要某种形式的岗位服务，因为主要的页面