我正在通过我的一个项目练习 DDD，这是我第一次与 DDD 互动。我有一个系统，有 3 种不同类型的用户，一位是厨师，一位是送货员，一位是一般用户。厨师是一个可以宣传他的食谱并接受订单的概念。送货员是注册的用户，其功能只是将食物送到各自的地址，而普通用户是想要订餐的用户。
据我了解，这三种用户属于 3 个不同的有界上下文，而不是“用户管理”或“身份管理”之类的用户。如果我错了，有人可以纠正我吗？
最佳答案
如果没有更多信息就无法确定，但这里有一些提示。
如果您正在考虑 CRUD“有界上下文”，例如“用户”、“厨师”、“送货员”，那么这些几乎肯定是错误的。上下文不是“实体”的 CRUD 服务，它们是语义上具有凝聚力的功能单元。
这里有一个实用的思考方法:如果两个限界上下文的消息双向流动，那么它们可能不是好的限界上下文。示例包括:获取用户/厨师/交付数据(请求-响应)、事件双向流动，或者双向同步。
这里有另一种思考方式:即使其他有界上下文发生故障，有界上下文也应该继续工作。 (它可能会慢慢过时，但它会继续工作)。
一些有界上下文的想法:
- 搜索
- 订购
- 交付
搜索 用于浏览餐馆/厨师等。请注意，这个东西不需要任何类型的通信。必要时数据会被推送到它，但即使 Ordering 和 Delivery 发生故障，它也会继续工作。
Ordering 包含一些用户数据，例如帐单地址、信用卡或其他数据，但不是全部。例如，它不需要送货地址。订购完成后，它只会将用户转发至Delivery。再次注意，即使 Search 或 Delivery 已关闭，此操作也能正常工作。
Delivery 将具有用户的送货地址并选择送货员，跟踪送货情况。再次注意:即使 Search 或 Ordering 关闭，这也能正常工作。
最酷的是，这三个人根本不需要任何直接沟通。如果所有这些都是基于网络的，他们可以简单地将用户链接(重定向)到下一步，用户甚至永远不会看到这些可能是不同的应用程序。
这个样式其实有一个名字，叫做Self-Contained Systems .
关于domain-driven-design - 食品配送用例中的有界上下文，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52977040/