Php 如果目前实际上没有必要的话，是否赞成将大命令分解为小命令？

我正在为一些商店实现后端，它完全写在前端，只有最终状态（数据）被发送到后端。我正在尝试将DDD与CQRS/ES一起使用

快乐场景用例（例如，一般化）：

• 给定该用户，Cart和CartItem存在
• 用户可以将类型为X的CartItem添加到购物车

• 用户可以指定（设置一些参数）carty项

• 用户可以添加类型为Y的CartItem

• 用户可以从他的地址中选择地址（创建地址是个问题） （公元前二世纪）

• 用户可以下订单

现在，因为这一切都发生在前端，所以我现在唯一的交付机制是来自GraphQL的一些原始数据。我是否应该在应用层中使用create方法create（$someGraphQLData）创建一些CreateNewOrderFromGraphQL；这只会创建相对较大的CreateNewOrderCommand（因为它需要包含地址、CartItems、促销代码等），并通过命令总线将其传递到创建整个订单的域模型中

或者我应该像在前端一样考虑我的域模型，然后在我的CreateNewOrderFromGraphQL中将大型原始GraphQL数据分解为单独的命令，如CreateCartCommand、AddItemToCartCommand、CreateOrderCommand（其中包括购物车id、地址id，可能还有一些细节），然后依次调用它们吗

---

我应该考虑什么

因为前端有很多行为，前端不可信，所以您不得不在后端复制行为。 那么，让我们看看你这里有什么

我认为您应该将域模型（命令端）设计成与UI无关的，其中GraphQL接口是一种UI

因此，如果用户存在，则在请求的授权阶段，您必须执行一项检查。如果用户不存在，则客户端请求不应到达域模型，应用层（或UI和域之间的类似层）应拒绝该请求

可以将购物车作为另一个

聚合
。它应该有像
CreateCartCommand
和
AddItemToCartCommand
这样的命令。或者，如果没有真正的不变量，它可以作为积垢来处理

然后，
OrderAggregate
可以有一个
PlaceOrderCommand
，其中cart中的项目作为参数，应用层已经检查了存在的
AddressId
和
UserId
。这个
Aggregate
保护它自己的不变量，比如
total price你的不变量是什么？在什么条件下可以创建和放置
订单
？您应该基于聚合的
不变量创建命令。@ConstantingAlBun订单可以创建，如果：1）给定id的用户存在2）给定id的地址存在3）购物车有效，则表示订单购物车中的每个CartItem都传递了自己的不变量。所以，我认为打破这一点更明智，所以我可以先创建购物车，然后一个接一个地添加项目，最后只需将购物车的id传递给订单。然后，我可能最终会在创建购物车（可能在许多步骤中）时报告特定项目的错误（但其他所有项目都可以处理ok），而不是不允许“使用给定的所有内容创建整个订单”？您无法控制前端吗？因为在DDD中，理想情况下，用户的意图与UI中的操作一直对应到后端。如果你不能做到这一点，我确实会尝试像你能做的那样工作，为你的前端创建一个外观，使前端看起来就像它自己在生成命令一样。如果有一天运气好的话，前端可以被更新/升级到理想状态，但是如果没有，你的后端也不会因此而受损。