相关疑难解决方法(0)

在我的项目中使用DDD方法.

该项目有聚合(实体)交易.这个聚合有很多用例.

对于这个聚合,我需要创建一个rest api.

用标准:创建和删除没问题.

1)CreateDealUseCase(名称,价格和许多其他参数);

POST /rest/{version}/deals/
{ 
   'name': 'deal123',
   'price': 1234;
   'etc': 'etc'
}

2)DeleteDealUseCase(id)

DELETE /rest/{version}/deals/{id}

但是如何处理其他用例呢？

• HoldDealUseCase(id,reason);
• UnholdDealUseCase(ID);
• CompleteDealUseCase(id,以及许多其他参数);
• CancelDealUseCase(id,amercement,reason);
• ChangePriceUseCase(id,newPrice,reason);
• ChangeCompletionDateUseCase(id,newDate,amercement,whyChanged);
• 等(共20个用例)......

有什么解决方案？

1)使用动词:

PUT /rest/{version}/deals/{id}/hold
{ 
   'reason': 'test'
}

但!动词不能在url中使用(在REST理论中).

2)使用完成状态(将在用例之后):

PUT /rest/{version}/deals/{id}/holded
{ 
   'reason': 'test'
}

就个人而言,它看起来很难看.也许我错了？

3)对所有操作使用1 PUT请求:

PUT /rest/{version}/deals/{id}
{ 
   'action': 'HoldDeal',
   'params': {'reason': 'test'}
}

PUT /rest/{version}/deals/{id}
{ 
   'action': 'UnholdDeal',
   'params': {}
}

在后端很难处理.而且,很难记录.由于1个动作具有许多不同的请求变体,因此已经依赖于特定的响应.

所有解决方案都有明显的缺点.

我在网上看过很多关于REST的文章.到处都只有一个理论,如何与我的具体问题在一起？

我在域中几乎没有不同的有界上下文.CRUD操作的验证建立在每个有界上下文中.

例如,只有创建它的人是组长,我才能创建一个名为GAME的实体.

在这个例子中我有两个有界上下文(BC).一个是游戏BC,另一个是用户BC.为了解决这个问题,在游戏BC中,我必须在继续创建游戏之前向用户BC进行类似IsGroupLeader()的域服务调用.

我不认为DDD推荐这种类型的通信.我也可以在游戏BC中拥有一个用户实体,但我不想这样,因为同一个用户实体在不同的BC中的不同上下文中的使用方式不同.

我的问题是:

1. 我是否应该使用域事件,其中游戏BC必须向用户BC发送事件以询问用户的状态？使用这种方法,我不会像IsGroupLeader那样进行同步调用,而是进行名为is_group_leader的事件.然后游戏BC必须等待用户BC处理事件并返回状态.只有在用户BC处理事件之后,游戏BC才会创建游戏实体.

2. CQRS是我问题的解决方案吗？

任何想法都赞赏.