看了领域驱动设计，读到领域模型是一种反模式，思考ok也许应该把更多的行为放到我们的领域实体中。行为将需要使用SOLID方法来处理灵活性，因此需要DI框架和容器来允许将一些行为注入实体中。然而，在连接实体时出现了不匹配，因为我们的实体可能来自实体框架或NHibernate等对象关系管理框架，而行为则来自依赖注入容器。
我猜你需要一种让ORM也能插入DI容器的方法。我只是想知道，当其他人想要获得更丰富的模型，同时又想使用ORM</
浏览 0提问于2013-12-07得票数 2
2回答
ORM实体与DDD实体
、、、、
我熟悉由服务、实体和存储库组成的典型分层体系结构。服务操作被存储库持久化的带注释的实体类。在这个模型中，实体类只是带有大量getter和setter的贫血数据容器。业务逻辑驻留在过程服务类中(由spring容器管理的单例)。
我把DDD作为一个业余项目来学习。在DDD中，实体形成了一个丰富的域模型，它在聚合根方法(和值对象)中容纳了大部分业务逻辑。服务几乎仅仅是协作实体、存储库和其他服务的<
浏览 4提问于2021-09-02得票数 3
回答已采纳
2回答
StackExchange上有很多解决方案，建议使用ORM模型作为域对象，这样您就可以在聚合上更改属性，并让ORM层区分并刷新对db的更改，如果我没有弄错的话，大多数示例都包含对Enity的引用。与这里的解决方案一样，作为域对象的项目包含ORM持久性逻辑
我对DDD的部分理解是，您不应该在域模型中定义任何持久性层逻辑。持久化逻辑应该在您的存储库中
浏览 0提问于2020-04-04得票数 4
6回答
我有一个丰富的域模型，其中大多数类都有一些行为和属性，这些行为和属性要么是计算出来的，要么是公开了成员对象的属性(也就是说，这些属性的值从未持久化)。如果我使用域实体，流将是
浏览 4提问于2010-02-04得票数 21
回答已采纳
2回答
我们正在对我们的(Java) web应用程序模式进行长时间的深入研究。在过去，我们遭受过过于贫乏的对象模型以及控制器、服务和DAO之间过度的过程分离，简单的值对象(基本上是数据袋)在它们之间移动。我们使用声明式(XML)托管ORM (Hibernate)来实现持久性。所有实体管理都在DAOs进行。
在尝试转向更丰富的域模型时，我们发现自己很难找到如何最好地设计持久层。我们将有一层无状态业务逻辑服务，
浏览 3提问于2011-01-16得票数 13
1回答
DDD域实体与持久化实体
、、、
在DDD中，我们说域实体不是数据库模型/实体的表示。我们还说，为了正确地从应用程序中提取域模型，域模型不应该包含任何关于它的持久化方式或返回给客户端的方式的信息。我遇到的问题是，在处理大多数ORM或数据库抽象时，我们需要用一些特定于数据库的注释来注释数据库实体，从而打破了规则。
这是否意味着我们应该为域创建一个实体，并为持久化创建另一个
浏览 20提问于2020-02-02得票数 3
5回答
在我使用Spring的web应用程序中，我有一个丰富的域模型。我想把这个域模型提供给客户端浏览器。例如，由于我的域模型包括一个带有Set<Person> getFriends()和DateTime getBirthday()方法的类Set<Person> getFriends()，所以我希望在客户端使用这些方法使用场景包括
动态更新访问浏览器的<
浏览 17提问于2013-03-04得票数 3
2回答
Martin将贫血域模型描述为领域驱动设计中的反模式.为了在域模型上具有业务逻辑，经常使用域服务。但是Vaughn Vernon认为将域服务注入域模型是有害的(参见“实现领域驱动设计，第387页”)。
在我看来，这些意见是矛盾的，这是真的吗？如何考虑这两点呢？它真的是丰富的领域模型，领域服务注入与贫血领域模型和正常领域服务？
浏览 0提问于2015-12-17得票数 19
回答已采纳
DDD中的域模型应该与持久性无关。对我来说，这似乎不是非常顽固的不可知论。
那么，如何将DDD和CQRS/ES结合起来，而不受这种持久化技术对领域模型的</e
浏览 5提问于2015-06-30得票数 4
回答已采纳
我们在服务层上定义了事务性注释，典型的spring hibernate crud通常是我应该替换哪一层。如果我回顾一下这个项目，很明显当时我对领域<em
浏览 44提问于2010-10-08得票数 86
回答已采纳
2回答
我在UML中看到了领域模型的思想，但是我从来没有机会在实际的代码中使用它们。现在我在数据库中看到了它们，特别是来自的SQL编码。有句话提到了域模型类：
那么我如何创建域类呢？当我处于“数据库上下文”(当我处于
浏览 3提问于2010-08-06得票数 0
回答已采纳
2回答
域模型和服务对象中的业务/域逻辑
、、、、
我正在尝试设计一个同时包含两个丰富模型的域层(贫血模型是糟糕的OO实践)。我还从DDD中了解到，它并不排除服务对象，良好的域层设计是域逻辑拆分成域模型和服务对象的健康平衡。但是，我想知道，如果业务逻辑应该在域模型和服务对象之间划分，那么应该在哪里划清界限？换句话说，我如何知道业务逻辑属于域模型还是属于服务对象？
浏览 0提问于2014-01-31得票数 0
3回答
我在过去使用过MDA (模型驱动架构)工具，我们通过UML建模，这产生了业务实体(我们的领域模型)和ORM (映射等)等等。在域上工作的许多业务代码和服务都是模型的一部分，我们的存储库正在返回业务实体(因此不可能切换到另一个ORM (不是我们想要的))。
然而，现在我开始一个项目，我想考虑从DDD的角度。到目前为止，我似乎将业务逻辑放在域模型中，
浏览 0提问于2011-12-11得票数 11
回答已采纳
我最近遇到了持久性无知的概念，您的域模型应该不了解应用程序的持久性层，这让我思考了一下。我一直在尽力保持应用程序的不同部分松散耦合，将类似ORM的东西封装在接口中，以便在需要时能够(相对地)轻松地将它们交换出去。然而，我确实发现了ORM的一些方面，更重要的是，底层数据库泄漏到我的域模型中，迫使我重新构造数据模型以适应数据库<em
浏览 0提问于2017-10-27得票数 0
回答已采纳
6回答
我似乎遗漏了一些东西，而谷歌的广泛使用无助于提高我的理解。我喜欢以持久无知的方式创建域模型，例如：解决这一问题的</
浏览 7提问于2011-10-07得票数 8
回答已采纳
3回答
DDD中分离域模型和持久化模型
、、、、
我一直在阅读有关领域驱动的设计，以及如何在使用代码优先方法生成数据库的同时实现它。根据我所读到的和研究过的，围绕这个问题有两种观点：
有一个类，它同时充当域模型和持久性模型。现在我知道意见1)可以简化域模型和持久性模型之间没有太多区别的小解决方案，但我认为它违背了单一责任原则，在ORM的约定干扰DDD时引入了许多问题。我的域模型</e
浏览 3提问于2014-07-11得票数 76
回答已采纳
2回答
我读过一些关于域驱动设计和丰富域模型，正如Martin Fowler所描述的，的使用的文章，我决定将其应用于个人项目中，而不是使用事务脚本。
在UI实现开始之前，一切都很顺利。问题是，一些视图将使用由不寻常的模型备份的丰富组件，因此，我必须将域模型转换为这些组件所使用的组件。在视图到域部分中，这种转换特别“复杂”，以至于涉及到了
浏览 0提问于2013-06-30得票数 7
回答已采纳
1回答
我正在开发一个使用事件源和CQRS的发票web应用程序。这使它对我来说更简单，但似乎与模式不同。在我读过的任何一篇文章中都没有提到这种方法。我喜欢在公交车上只传递
浏览 0提问于2015-08-05得票数 3
但是，使用提供更改跟踪的ORM的方法似乎相互排斥。如果我有一个查询的“通道”作为RO获取我的对象，那么就没有任何变化可跟踪。如果我有另一个用于CUD+命令的通道，它更像是一个带有轻量级DTO的RPC，然后将自跟踪实体合并到一个较低的层。
如何调和这两种方法(CQRS / ORM +STE)？
浏览 3提问于2011-04-08得票数 11
云服务器
ICP备案
云直播
腾讯会议
实时音视频
腾讯云开发者
