Domain driven design 食品交付用例中的有界上下文
我正在我的一个项目中练习DDD，这是我第一次与DDD互动。我有一个系统，它有三种不同的用户，一种是厨师，一种是送货员，还有一种是普通用户。厨师是一个可以为自己的食谱做广告并接受订单的概念。送货员是一个注册用户，只负责将食物送到各自的地址，而普通用户则是一个想要订购食物的用户Domain driven design 食品交付用例中的有界上下文,domain-driven-design,object-oriented-analysis,Domain Driven Design,Object Oriented Analysis,我正在我的一个项目中练习DDD，这是我第一次与DDD互动。我有一个系统，它有三种不同的用户，一种是厨师，一种是送货员，还有一种是普通用户。厨师是一个可以为自己的食谱做广告并接受订单的概念。送货员是一个注册用户，只负责将食物送到各自的地址，而普通用户则是一个想要订购食物的用户 据我所知，这三类用户属于3种不同的有界上下文，而不是“用户管理”或“身份管理”。如果我错了，有人能纠正我吗？如果没有更多的信息，这是不可能的，但这里有一些提示 如果您考虑CRUD“有界上下文”，例如“用户”、“厨师”、“送货
据我所知，这三类用户属于3种不同的有界上下文，而不是“用户管理”或“身份管理”。如果我错了，有人能纠正我吗？如果没有更多的信息，这是不可能的，但这里有一些提示 如果您考虑CRUD“有界上下文”，例如“用户”、“厨师”、“送货员”，那么这些几乎肯定是错误的。上下文不是“实体”的CRUD服务，它们是语义上具有内聚性的特征单元 下面是一个实际的思考方法：如果两个有界上下文的消息双向流动，那么它们可能不是好的有界上下文。示例包括：获取用户/厨师/交付数据（请求-响应）、事件双向流动，或者双向同步 这里有另一种思考方式：即使其他有界上下文停止工作，有界上下文也应该继续工作。（它可能会慢慢过时，但会继续发挥作用） 一些有界的想法：
- 搜寻
- 订购
- 交付
搜索订购交付订购配送SearchDeliveryDeliverySearchOrdering这种风格实际上有一个名字，叫做。IMO，这个问题太宽泛了，而且是基于观点的。谢谢@Robert提供了如此详细的答案，让我为问题空间提供更多的上下文，因此我正在从事的项目是一个食品配送服务，它以一种方便用户搜索厨师的方式，来自厨师的订单正在提供，厨师接受/拒绝订单，如果厨师接受订单，那么下订单的用户可以跟踪食品的进度，一旦食品准备好，送货员会收到通知，通知他们准备好将食品送到某个地址，并通过现金支付。因此，将有三种不同类型的参与者注册到平台上，一种可以烹饪食物，我们称之为厨师，一种想要食物，因为他们是客户，送货员可以帮助将食物交付给合适的人。我在为他们的认证/授权设计服务时陷入了陷阱，它应该分为一个有界上下文（IdentityManagement）或三个不同的有界上下文（customer account management、chef account management、delivery man account management）。因为他们都是用户，但反映了完全不同的概念。Thanks@MuhammadSufyian需要考虑的是，用户管理将是您解决方案的一部分，但它是身份验证的一部分吗？它真的是您的问题域的一部分吗？我想说的是你不需要把所有的事情都记录下来！罗伯特，我同意你的回答，但我怀疑当其他服务停止时，一个服务是否能做任何有意义的工作。例如，如果搜索关闭，订购将不会收到订单，因为用户找不到任何东西。如果送货停止，订单将无法接收订单，因为结账过程要求送货员接受送货地址并验证餐厅是否可以送货到该地址。等等我同意“已经触发的流程”应该能够在单个服务中完成，而不需要其他流程。