Tag: 域驱动设计

如何在DDD中实现持久无知？: 我正在处理涉及Workspace的项目的持久层，每个项目可能包含零个，一个或多个Document 。（我试图遵循领域驱动设计原则，但我的问题可能与此没有直接关系。）问题1：我应该分离出持久性吗？即，您是否以这样的方式设计实体和价值类在内存中创建实体和值，就像没有持久性一样（可能使用Factory方法Workspaces.newWorkspace(…) ），以及调用一个单独的persist()方法（可能在存储库中）来处理持久性？或者我的工厂方法Workspaces.newWorkspace()应该创建一个持久化实体（一旦事务关闭就会持久化）？如果这个问题的答案是“分离，伙计！” 然后我想知道如何以优雅的方式实现这一目标。我的第一种方法是（在Scala伪代码中）： class Workspace(title: String, documents: List[Document], id: Option[Long]) { def add(d: Document) = // … def remove(d: Document) = // … } 但是，如果工作空间可以包含许多文档，则这不是很好（受RAM限制）。我的下一个方法是“如何不向实体注入服务” ，这是： class Workspace(title: String, docSupplier: DocSupplier, id: Option[Long]) { def add(d: Document) = docSupplier.add(d) def remove(d: Document) = docSupplier.remove(d) } […]

解耦模型和输入检查: 将输入检查与模型分离并将其处理到其他地方（例如控制器）是一种好的做法吗？如果是这样，怎么可以从MVC或DDD的角度来做呢？

DDD – 实体状态转换: 考虑以下简化示例： public class Ticket { public int Id; public TicketState State; public Ticket() { // from where do I get the “New” state entity here? with its id and name State = State.New; } public void Finished() { // from where do I get the “Finished” state entity here? with its id and name State […]

如何解决松散耦合/dependency injection与富域模型之间的冲突？: 编辑：这不是理论层面的冲突，而是实施层面的冲突。另一个编辑：问题是没有域模型作为仅数据/ DTO与更丰富，更复杂的对象映射，其中Order具有OrderItems和一些calculateTotal逻辑。具体问题是，例如，Order需要从中国的某些Web服务中获取OrderItem的最新批发价格（例如）。因此，您运行了一些Spring Service，允许在中国调用此PriceQuery服务。 Order具有calculateTotal，它遍历每个OrderItem，获取最新价格，并将其添加到总数中。那么您如何确保每个订单都引用此PriceQuery服务？如何在反序列化，从DB加载和新实例化时恢复它？这是我的确切问题。简单的方法是传递对calculateTotal方法的引用，但是如果您的Object在其整个生命周期内部使用此服务该怎么办？如果它在10种方法中使用怎么办？每次传递引用都很麻烦。另一种方法是将calculateTotal移出Order并进入OrderService，但这会打破OO设计，我们会转向旧的“事务脚本”方式。原帖：简短版本：富域对象需要引用许多组件，但这些对象会被持久化或序列化，因此它们对外部组件（在本例中为Spring bean：服务，存储库，任何东西）所持有的任何引用都是暂时的并且会被消除。当对象被反序列化或从DB加载时，需要重新注入它们，但这非常难看，我看不到一种优雅的方法。更长的版本：有一段时间了，我在Spring的帮助下练习了松耦合和DI。这对我保持可管理性和可测试性有很大帮助。不久前，我读了Domain-Driven Design和一些Martin Fowler。因此，我一直在尝试将我的域模型从简单的DTO（通常是表行的简单表示，只是数据无逻辑）转换为更丰富的域模型。随着我的域增长并承担新的职责，我的域对象开始需要我在Spring上下文中使用的一些bean（服务，存储库，组件）。这已成为一场噩梦，也是转换为丰富域名设计最困难的部分之一。基本上有些点我手动将应用程序上下文的引用注入到我的域中：当从Repository或其他负责实体加载对象时，因为组件引用是暂时的，显然不会持久化从Factory创建对象时，因为新创建的对象缺少组件引用当对象在Quartz作业或其他地方被反序列化时，因为瞬态组件引用被擦除首先，它很难看，因为我将对象传递给应用程序上下文引用，并期望它通过名称引用它所需的组件。这不是注射，而是直接拉动。其次，它是丑陋的代码，因为在所有提到的地方我需要逻辑来注入appContext 第三，它容易出错，因为我必须记住在所有那些地方注入所有这些物体，这比它听起来更难。必须有一个更好的方法，我希望你能够对它有所了解。

Java的完整堆栈框架: 我正在寻找Java的完整堆栈框架（从持久性到视图生成（CRUD））。我没有像Grails这样的Rails样式框架的经验，但我在Hibernate，Struts，Spring等方面做了很多工作…… 我更喜欢一个框架，让你自然地用更少的努力修改业务领域设计（即编写sql查询来修改表和约束，更改视图页面等等）。我看了一下这个话题，我看到了Naked Objects，但它的开发已经停止了。所以，我想听听你的经历。提前致谢。

如何在DDD中管理域逻辑和事件之间的事务？: 我正在研究DDD和事件源中的编程。我看到一个例子，当一个域逻辑被调用时（例如Order.placeOrder() ），它会发布一个事件（例如OrderPlaced ）。事件将作为事件存储发送到MQ。域逻辑（ Order.placeOrder() ）应该是一个primefacesAPI，如果使用Spring作为事务管理器，它应该有@Transactional注释。现在我的问题是：如何确保数据库更改和事件发送在同一个事务中？即如果在将数据提交到DB时出现任何错误，则该事件永远不应发送给MQ。我知道有像XA或2阶段提交这样的解决方案来强制数据库更新并在同一事务中发送MQ消息。但似乎现在还没有广泛使用。如果仍然使用Spring @Transactional注释而没有XA，那么在事务成功提交后我们可能会做一些逻辑吗？这样做的最佳做法是什么？

关于“贫血领域模型”被认为是反模式的具体例子: 如果这是重复，我道歉，但我在相关问题中找不到关于该主题的任何具体示例。在阅读了Martin Fowler关于“贫血领域模型”的文章之后，我不知道为什么这被认为是一种反模式。大多数企业开发人员甚至认为它是一种反模式，因为AFAIK可能有90％的j2ee应用程序是以“贫血”方式设计的？有人可以推荐进一步阅读这个主题（除了“领域驱动设计”一书），甚至更好，给出一个具体的例子，说明这种反模式如何以一种糟糕的方式影响应用程序设计。谢谢，

org.hibernate.MappingException：实体映射中的重复列: 我正在做一个简单的民意调查系统。我有2张桌子： Person ：身份证，姓名，姓氏 Vote ：ID，投票（布尔），VoterID（实际上是FK_PersonID ），PersonID（这实际上FK_PersonID ）。我需要能够识别谁投票以及投票的对象 – 使用存储在Person表中的Person来满足这些需求。表Person包含可以“投票”以及“投票”的人的用户详细信息。人们可以决定是否要为自己投票。我在我的domain对象中映射了我的表，如下所示：人 private Integer ID; private String name; private String surname; @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = “ID”) public Integer getID() { return ID; } public void setID(Integer ID) { this.ID = ID; } @Column(name = “name”) public String getName() { return […]

重构访问遗留系统中存储库的域逻辑: 我正在使用具有贫血域模型的遗留系统。域具有以下实体类： Car ， CarType ， CarComponent ， CarComponentType 。对于其中的每一个，都有一个单独的存储库。还有许多服务可以访问这些存储库，并且基本上包含所有逻辑。我需要实现一个方法来确定供应商CarComponentType可以停止CarComponentType 。逻辑如下：只有当前没有现有汽车的组件才能停止组件。最初，我在服务类中实现了它。 public boolean canBeDiscontinued(CarComponentType carComponentType) { List cars = carRepository.getCarsWithComponent(carComponentType); return cars.isEmpty(); } 这有效 – 但是这个逻辑在代码中的其他几个地方使用。它可能会增长，它看起来像是可以放在 CarComponentType类中的东西： public boolean canBeDiscontinued() { List cars = carRepository.getCarsWithComponent(this); return cars.isEmpty(); } 但是，我不能把它放在那里，因为它需要访问存储库（据我所知，它是一个非常严重的反模式，实体要知道数据访问层）。加载组件类型时，我无法加载该类型的所有汽车，因为这可能是数千个对象。我们没有使用任何ORM，因此制作延迟加载的集合不仅体积大，而且非常容易出错。像我第一次在服务类中实际使用此方法更合适吗？这不重要吗？还有另一种选择吗？我应该从另一个起点开始重构吗？这里有一个类似的问题。但是我的问题与Java有关，所以我不认为这个解决方案适用于我的情况。此外，抱歉使用汽车和组件作为我的域模型。 🙂

程序设计 – 按function与层或两者打包？: 我正处于Web应用程序的设计阶段，该应用程序允许用户创建工作请求，工作人员可以根据这些请求投入时间。该应用程序还将为主管提供报告function，以获取每日总计，报告和帐户所花费的时间，“成本分配”。我过去使用的应用程序是使用逐层方法设计的。我认为通过function设计使用包会更有效率，我对这个设计有疑问。我目前正在考虑的function包：请求 – CRUD请求，然后分配，添加发票号等… 工作时间 – 用户针对请求，假期，培训或会议的每日时间成本分配 – 创建报告，会计师想要的会计事项…… 前端将是Tomcat服务器和JSP。而且，后端将是一个Oracle数据库，EclipseLink执行持久性。我的问题：在我对按function分组的理解中，实体和DAO将进入与它们相关联的包。在多个包中展开持久层。将包从其他包中调用实体。所有的重叠是否真的有用？包之间没有隔离。使用打包function有什么优缺点？使用额外的持久层是否是一个好的设计？或者，我是否完全理解这一点？