《DDD》专题

域单元测试 正如您所看到的，这两个测试都检查用户余额是否为0，这是域责任。因此，问题是：应用层单元测试应该是什么样子的，它应该测试什么？我在某处读到单元测试应该在“流控制的应用服务和业务规则的域模型”中进行测试。谁能再详细说明一下，给出一些例子，应用层单元测试应该测试什么，看起来是什么样子的吗？

我的应用程序遵循DDD设计原则。它是一个ASP.NET MVC应用程序，其中MVC web应用程序是表示层（我将控制器移到了应用层）。它还有应用层，主要是应用服务、用例等。应用层之上是域模型所在的域层。然后是基础结构层，它位于所有其他层之上，并且不依赖于其他层。 但是我注意到一个问题，如果持久化逻辑像DDD书中所说的那样进入基础结构层，基础结构层就会依赖于域层。例如，存储库需要知道要创建的领域模型

快住手！域模型不是持久性模型 如果这是真的，将持久性对象与域对象分开有什么好处呢？

我想知道你是否能帮忙。我正在编写一个订单系统，目前已经实现了一个订单微服务来处理下订单。我正在使用DDD与事件源和CQRS。 订单服务本身接收生成事件的命令，实际的订单服务侦听自己的事件以创建读取模型（这里的想法是使用CQR，因此用于写入的命令和用于读取的查询） 在执行上述操作后，我遇到了一个问题，可能只是我没有完全理解正确的方法。 一个订单实际上有依赖项，这意味着一个订单需要一个客户和一个产品。

我将在Spring中使用DDD构建一个新应用程序。我将有一个REST适配器、一个JPA适配器和我的域模型。 我的问题是在哪里进行现场验证？假设我有一个REST方法来下订单，我应该在哪里验证请求中的订单数量是否大于0？在REST适配器的DTO中？或者在我的域实体中，因为验证应该是业务逻辑的一部分？ 如果我在REST请求的DTO中进行验证，我就可以将验证检查添加到DTO的字段中，并在我的REST控制器

在我的业务逻辑中，可以通过他/她的手机号码来识别。第三方验证系统确保客户的电话号码真实存在，并在将记录插入表格之前检查唯一性。在我看来，已经是唯一的，所以是不必要的。 这是我当前的课程当前是类中的值对象。 我想改变如下。 如果在聚合根或实体中使用非UUID Id，是否存在任何缺陷？

我们正在尝试遵循DDD的原则，同时开发我们的新应用程序。EF2.1用于持久化实体。 我们有很多场景，其中一个具有一个聚合的实体可能引用另一个聚合中的某些内容。例如，我的订单有一个客户的参考。在订单实体上，我们通过持有外键值来实现这一点。过于简化的模型。 我们不将Order对象上的任何导航属性包含到Customer对象，因为它模糊了聚合的边界 对于可能需要列出订单并包含下订单客户姓名的需求，团队首选

在CQRS ES和DDD中，聚合中的小读模型从其他聚合或有界上下文中获取数据是件好事吗？ 例如，在订单验证（订单聚合）中，有一个业务规则，该规则仅在未标记客户时验证订单。标志信息通过同步域事件放入读取模型（特定于聚合）。 你怎么看？

我需要一些关于用户身份和访问域建模的澄清。用户域模型有一个联系信息实体（实体，因为它是可变的），客户可以注册一个电话号码，但可以在需要时选择更改。 客户使用过的电话号码永远不会被其他用户使用。因此，我认为该模型必须允许查询电话号码表（因为它与客户是多对一的，因为旧号码被停用并存档）。 如果创建domainservice是可以的，那么存储库应该是什么，因为没有确定聚合。在这些情况下，我有一个客户（用

我的示例DDD系统包含两个微服务，每个微服务都为特定上下文定义——用户域微服务和房地产域微服务。 我很清楚聚合根是管理业务实体的单一入口点，例如用户（聚合）可以是属性的所有者（来自第二个上下文的聚合），因此属性的管理是通过UserAggregate执行的。 我不能完全理解的是它在API和用例设计方面是如何应用的——假设我已经创建了我的个人资料，并且我想添加一个房地产作为我的归属。 如何确定是否应将

我正在尝试创建一个简单的博客平台，同时了解有关DDD和微服务的更多信息，因此我想在此上下文中向您询问两个建议： < li >我在我的项目中假设的一个业务规则是，只有角色为< code > publicis 和< code>Administrator的用户才能创建帖子，但是由< code > publicis 创建的帖子在发布之前必须首先得到< code>Administrator的批准。在我的理解

我不太确定如何使用actors访问数据库。在Akka的文档和书籍中，这个主题似乎被省略了。 一种解决方案可以是无状态参与者中的包装DAO。例如，对于数据库中的每个表（或域对象类型或聚合类型），可以创建一个负责所有CRUD操作的参与者。这种方法的一个变体可以是命令和查询的分离。例如，对于每个数据类型，1个命令参与者（用于并发）和10个查询参与者（用于并行性）。 另一种方法可以是创建只表示数据库中一行

域内有一个接口“DetectPriorityInterface”。两个实现必须同时处于活动状态；一种“混合”必须实时地选择一种而不是另一种。 问题是：这些实现（两个实现）应该住在哪里：在域层还是基础结构层？？ 内部实现充满了业务规则，应该驻留在域层。外部实现是一个简单的调用，应该存在于基础结构中。 null 客户端使用接口，因此，对于应用层，所有这些东西都是trasparent；接下来，我们将删除

在我的应用程序中，我有以下层： 表示层 Web服务层 应用程序服务层 域层 基础结构层