DDD中的领域对象建模哪一个更好？
在DDD（领域驱动设计）中，领域对象建模有两种常见的方法，分别是贫血模型（Anemic Domain Model）和充血模型（Rich Domain Model）。这两种方法在不同的场景下有不同的优势和应用场景。
- 贫血模型（Anemic Domain Model）： 贫血模型是指将领域对象中的业务逻辑和状态分离，将业务逻辑放在服务层或者领域服务中进行处理，而领域对象只包含数据和对数据的简单操作。贫血模型的优势在于简单、清晰，易于理解和维护。它适用于业务逻辑相对简单、领域对象主要用于数据传输和存储的场景。
推荐的腾讯云相关产品：无
- 充血模型（Rich Domain Model）： 充血模型是指将领域对象中的业务逻辑和状态封装在对象内部，使得领域对象具有自主性和行为能力。充血模型的优势在于领域对象更加贴近实际业务，具有更高的内聚性和封装性，能够更好地表达业务逻辑和规则。它适用于业务逻辑复杂、领域对象需要具备一定行为能力的场景。
推荐的腾讯云相关产品：无
需要注意的是，贫血模型和充血模型并不是绝对的对立，而是在不同的场景下选择合适的模型。在实际应用中，可以根据具体业务需求和团队技术水平选择适合的模型。
相关·内容
1回答
我很困惑如何在领域驱动设计中更新实体
domain-driven-design、clean-architecture、ddd-repositories
我正在学习DDD，遇到了一些麻烦。我创建了带有值对象的富域模型和一些用于操作模型属性的函数。目前，我正在内存DB中使用，我的域模型保持不变。一切都很好。但是现在我想把领域模型和DB模型分开。
用于创建(比如“音乐会”)的场景：
command.Application 用户发送服务获取域模型，然后应用服务调用存储库来坚持modelRepository (基础结构层)将该域模型转换为他的DB模型并写入DB。
第二个场景(我想更新“音乐会”)
用户发送命令更新concertApplication服务调用存储库，以获得“音乐会”更新(首先询问存储库在这里应该返回什么，它需要返回域模型或其他什么) co
浏览 3提问于2021-11-05得票数 2
回答已采纳
2回答
在MVC5应用程序中使用设计模式
c#、.net、design-patterns
我知道这里描述的四人帮设计模式：
Martin谈到了贫血的域模型(其中使用了服务层，域对象仅包含状态，即不包含任何行为)。富域模型意味着域对象包含状态和行为。我有两个问题：
公平地说，“四人帮”设计模式是针对富域模型(而不是贫血)的，因为示例中的大多数类都包含状态和行为？
这些模式是否仅针对业务逻辑层？例如，假设您有一个具有以下层的MVC5应用程序：
- Presentation: MVC5
- Business Logic Layer: Rich Domain Model
- Data Layer: Entity Framework
在本例中，表示层有Model类，数据层
浏览 9提问于2016-08-07得票数 1
2回答
贫血域模型与实体的区别
entity、domain-driven-design、anemic-domain-model
我试图对DDD有一个明确的了解，并阅读了Evans关于领域驱动设计的书和他们描述的Julie的博客：
Anemic Domain Model是一个以状态管理为重点的类模型。很适合吃渣滓。
Entity作为一个可变类，具有用于跟踪和持久性的标识。
肯定都是为了同一个目的，还是我完全搞错了？这两者有什么区别呢？我读过一个贫血的领域模型经常用来表示数据库模式，但是对于一个实体来说不是一样的吗？
例如，一个名为Customer的table具有：
CustomerId int
Forename varchar(50)
Surname varchar(50)
IsActive bit
根据我的理解，表示这
浏览 4提问于2014-09-09得票数 3
回答已采纳
10回答
富域模型与贫血域模型
domain-model、anemic-domain-model、rich-domain-model
我正在决定是否应该使用富域模型而不是贫血域模型，并寻找这两种模型的好例子。
我一直在使用一个贫血的域模型构建web应用程序，该模型由服务->存储->存储层系统支持，使用FluentValidation进行BL验证，并将我的所有BL放在服务层。
我读过Evan的DDD书，他(以及Fowler和其他人)似乎认为贫血的领域模型是一种反模式。
所以我只是想了解一下这个问题。
另外，我真的在寻找一些富域模型的好(基本)示例，以及它提供的贫血领域模型的好处。
浏览 17提问于2014-04-26得票数 119
2回答
领域驱动设计中的领域模型与领域模型
design-patterns、anti-patterns
我最近读了一篇关于"“的文章，引起了我的注意。当我阅读这篇文章时，我发现贫血的领域模型描述适用于我所从事和构建的许多项目。我从来没有认为这是一个糟糕的设计决策，因为它感觉非常自然。我认为，在重量轻且不太复杂的情况下，贫血领域模型的名称非常适合。为什么在领域模型中增加复杂性，而不需要仅仅是因为“贫血域模型”的标题不能恰当地描述您的代码？
问题：在什么时候将更多的代码复杂性填充到服务/应用程序层变得正确，而倾向于将实体对象的复杂性暴露出来？我完全赞成在一个实体上有一个“总计”属性，在这个属性中，它可以在内部计算出“总计”的值。我不想让实体直接与其他各种类型通信，以确定其中一个属性的结果。那
浏览 2提问于2009-07-21得票数 16
回答已采纳
1回答
在富领域模型和贫血域模型的上下文中，“模型”的实际含义是什么？
oop、symfony、model-view-controller、domain-driven-design、solid-principles
如果这个问题已经得到回答，我提前道歉，但我还没有找到模型在这种情况下的实际含义的定义，我实际上摸索。
我听说过术语模型仅用于描述持久层、所有特定于域的代码，或仅用于描述域实体。根据我所读到的，贫血领域模型似乎被认为是一件坏事，但为什么我似乎不太合拍的具体原因，我认为这是因为我不知道在这种情况下是指什么模型。我们这是针对MVC的吗？
如果只是引用实体，那么只将保持数据完整性的逻辑放在实体中并将实际使用这些实体的逻辑放入服务类中有什么问题？这还算贫血吗？如果是这样的话，您如何才能在不违反单一责任原则的情况下实际实现富领域模型。
答案不需要特定于框架或语言，但如果重要的话，我会使用php和Symfo
浏览 1提问于2014-05-28得票数 1
3回答
“将业务逻辑代码迁移到我们的域模型中”是一个好主意吗？
hibernate、spring、jpa
我正在阅读Hibernate in Action，作者建议将业务逻辑转移到我们的领域模型中(第306页)。例如，在本书提供的示例中，我们有三个名为Item、Bid和User的实体，作者建议将placeBid(User bidder, BigDecimal amount)方法添加到Item类中。
考虑到我们通常有一个不同的业务逻辑层(例如Spring中的Manager或Service类)来控制事务等，这真的是一个好建议吗？不向我们的实体添加业务逻辑方法不是更好吗？
提前谢谢。
浏览 3提问于2010-04-08得票数 31
1回答
DDD -贫血与富领域模型
architecture、domain-driven-design
我读过Eric Evan的DDD一书，他(以及Fowler和其他人)似乎认为贫血域模型是一种反模式。
所以我真的很想深入了解这个问题。
此外，我真的在寻找富领域模型的一些好的(基本)示例，以及它提供的相对于贫血域模型的好处。
浏览 0提问于2019-09-30得票数 2
3回答
抽象层控制服务对非规范化db实体的访问
c#、architecture、database、layers、nhibernate
我们的db被优化为最小的连接计数(部分非规范化)。例如，我们的User实体包含帐户数据(昵称、facebook id等)、用户数字统计(玩过的游戏总数、总赢数等)、与行会相关的用户信息(公会标识、成员类型等)等等--所有内容都在同一个表中。
我们使用ORM - NHibernate.user表(连同所有字段)映射到User类。
现在，我正在重构一个模型类AccountManagementService，它提供了在封闭的User上执行一些操作的可能性。模型有两个依赖项: NHibernate和User实体。模型逻辑严格地绑定到ORM方法(执行选择、执行更新)。
我认为这是不好的，模型知道这么多的
浏览 0提问于2015-06-20得票数 3
1回答
模型“克隆”增加了N层MVC项目的复杂性？
design-patterns、architecture、mvc、model、n-tier
我和一位朋友讨论了我的一个项目结构，他指出了一个有趣的观点，就是我的架构似乎通过对现有模型的“克隆”将复杂性和过度抽象引入到了我的层中。
总的来说，我的项目结构是这样的：
[UIL] ---- Consumption / U.I. Layer (Just for the sake of completeness with respect to the architecture’s explanation)
- Models (ViewModels & Mapping)
- Controllers
- Views
[API] ---- Service/API L
浏览 0提问于2017-10-03得票数 5
回答已采纳
3回答
DDD -贫血结构域模型是一种反模式吗？我们应该使用富域模型吗？
domain-driven-design、spring、anti-patterns
贫血领域模型很久以前就受到埃文斯和福勒的批评，因为它显然违背了面向对象的原则，等等。
然而，在最近几年，有不同的声音声称它根本不是反模式，这是一个遵循坚实原则的例子。
我已经使用Spring框架工作了这么多年。每个公司的每个项目都有一个包含业务逻辑的服务层，使用运行在贫血模型(JPA实体)上的存储库。此外，大多数示例，甚至是Spring的官方示例，都展示了这种工作方式。
我的问题是:贫血域模型是否仍被视为反模式？我们都做错事了吗？你不认为拥有Rich模型违反了坚实的原则吗？
浏览 0提问于2017-10-22得票数 16
2回答
对于需要在持久化之前创建关系的实体插入，我的代码应该放在哪里？
c#、linq-to-sql、anemic-domain-model
情境:我正在为我的“持久层”使用LinqToSql (可能被认为是无关紧要的)，并试图解决一些架构上的问题，比如某些与业务相关的逻辑应该放在哪里。
场景:应用程序的用户创建一个新订单。当他们这样做时，需要将产品密钥集合与该订单相关联。
我的第一个尝试是将所有这些jazz放在一个OrderService类中。然后，我尝试使用partial方法将其与我的DataContext结合：
partial void InsertOrder(Order instance)
{
var productKeys = this.ProductKeys
.Where(x =&
浏览 4提问于2012-03-14得票数 2
1回答
贫血域模型与活动记录的差异
design-patterns、activerecord、anemic-domain-model
基于的答案，我发现贫血领域模型背后的相同想法在活动记录中！在active record模式中，数据库字段与域属性相同(如果我错了，请纠正我的错误)，因此根据前面提到的答案，我们在贫血模型中也有相同的内容(很容易从数据库表自动生成)，那么这两种方法之间有什么区别呢？谢谢
浏览 5提问于2014-03-14得票数 1
回答已采纳
1回答
将领域模型标记为贫血的标准是什么？
domain-driven-design、domain-model、anemic-domain-model
到目前为止，我还没有看到一篇博客文章或文章描述了将领域模型标记为贫血的客观标准。我认为，为贫血领域模型设定客观标准肯定会有所帮助。
几年前，我设计了一个域模型。我在数据库中只有很少的表(大约7个)。我在代码中创建了完全相同数量的类。我为这些类中的每一个实现了存储库模式。今天，我明确地感觉到它是一个贫血域模型。我有机会设计一个面向对象的领域模型，但我设计的领域模型本质上是关系模型。根据我的经验，我定义的一个标准是-如果对象模型与您的关系模型一对一映射，那么它可能是贫血域模型的标志。
有没有其他可能指向贫血领域模型的标准？
谢谢。
浏览 0提问于2013-05-05得票数 1
3回答
DDD如何处理动态业务规则？
domain-driven-design、architectural-patterns
DDD被选择作为一种架构模式来驯服一个野生的数据库模型，以及无处不在的语言。然而，我们的模型有一个棘手的部分--许多规则都是动态的，我不知道如何将它们与我对DDD的理解相协调。
class Account {
private Mailing[] mailings;
void SubscribeToMailing(Mailing m) {
if (/* this is allowed */) {
mailings.Add(m);
}
}
}
我遇到的问题是“这是允许的”检查必须在运行时确定。可以为系统配置条件规则。
浏览 0提问于2020-09-22得票数 1
回答已采纳
2回答
如何使用NHibernate ISet简单地将IList映射为AutoMapper
nhibernate、mapping、automapper
我试图使用AutoMapper从DTO映射到我的域。
我的DTO可能是这样的：
public class MyDTO
{
public string Name { get; set; }
public bool OtherProperty { get; set; }
public ChildDTO[] Children { get; set;}
}
public class ChildDTO
{
public string OtherName { get; set; }
}
我的域对象如下：
public class MyDomain
{
publi
浏览 0提问于2009-11-09得票数 2
1回答
当需要依赖项时，如何/将业务逻辑放置到EF实体？
.net、entity-framework、architecture、dependency-injection、domain-driven-design
我正试图为我的应用程序编写一些业务逻辑。我的应用程序的核心是从数据库第一模型生成的EF实体。我已经将生成的类(.tt文件)与.edmx部件分开。
我想找到放置业务逻辑的最佳位置，但的问题是，业务逻辑需要一些复杂的依赖项，例如，需要日志记录、调用一些WebService或对DB进行纯SQL调用。因此，我不能只在函数内部使用()并创建硬依赖关系，但我希望能够按照DI原则从它们抽象出。
public class Person
{
public Person(IDbCaller dbCaller, IWebServiceCaller webServiceCaller) { }
}
我的第一个赌
浏览 4提问于2014-06-05得票数 2
回答已采纳
3回答
如果我们在API中不使用DTO，会发生什么？
c#、asp.net-web-api
例如：“学生会”是领域模型，我在我的API操作方法中直接使用“学生”对象。
// Domain Model.
pubic class Student
{
public int Id { get; set; }
public string FirstName{ get; set; }
public string LastName { get; set; }
public string Gender{ get; set; }
pub
浏览 1提问于2018-12-10得票数 1
回答已采纳
4回答
在一个小项目中使用OOP方法来组织业务规则，而不是SOA。不包括DDD，是否有什么策略来做到这一点？
object-oriented、domain-driven-design、repository、soa
有一天，我和一个朋友讨论了小项目中的OOP问题。在我和他工作的大多数项目中，SOA是规则。
例如，想象一下SOA应用程序中的订单。该应用程序的场景可以是：
许多服务(UpdateOrderService、CreateOrderService等)相互调用。
订单的数据都是开放的(大量的getter和setter)，可以对任何服务进行操作。
业务规则分布在许多服务中。
正如沃恩·弗农( Vaughn )在他的一本书中所说的那样，这种策略对于更复杂的商业规则的大型项目来说，不会有很好的效果。我们很多人也知道这一点。
顺便说一句，SOA有很多不同的含义，我采用了一个简单的含义，由Vernon描述:服务
浏览 0提问于2018-01-23得票数 1
2回答
富域模型、封装和构造器过度注入问题
design-patterns、dependency-injection、single-responsibility
我正在重构一个电子商务网络应用程序，目前正在处理UserBasket类，它将不得不处理添加或删除项目，更改它们的数量，获取总量，项目总数等。在显示篮子时，还需要项目的名称、描述和主图像文件名.
然后，UserBasket必须知道给定数量的Item的价格。计算当前适用价格的不同方法应可互换。我可以在某种类型的Strategy模式中使用ItemPriceGetter模式来构造UserBasket，让项目不知道这一点，或者用PriceFindingStrategy构造Item本身。
我对一个完全贫血的领域模型持保留态度。一个项目应该能够告诉我它的价格为某一客户和数量在某一特定日期-它应该能够告诉文件
浏览 0提问于2015-03-23得票数 1
回答已采纳
扫码
添加站长 进交流群
领取专属 10元无门槛券
手把手带您无忧上云
相关资讯
热门标签
云服务器
ICP备案
实时音视频
对象存储
云直播活动推荐
腾讯云开发者
