我正在设计膳食计划应用程序。我希望它有：
- 带食谱的典型食谱(用户可以将食谱添加到食谱中，其中包含配料清单，包括用量、份量、根据配料计算的卡路里量，配料可以添加到购物清单中，食谱本身也可以添加到用餐计划中(。食谱可以通过一些过滤器来搜索，比如烹饪类型等
- 膳食计划-每个工作日可修改的食谱列表
- 成分目录-可以通过过滤器搜索成分，每个成分都有一些值，例如卡路里。也许它会有计算器来测量(比如一勺面粉里有多少克(
- 购物清单-用户从食谱或手册中添加的成分清单，可以删除，也可以修改数量
至于架构，我希望它是基于微服务的应用程序。我读过一些书，比如构建微服务、快速领域驱动设计以及一堆文章和教程。然而，我不知道如何切片域来识别有界的上下文，这些上下文将是微服务。我脑海中浮现的只是划分，就像我指出的食谱、计划书，配料目录和购物清单一样，但我不确定这是否是在我的应用程序中设计模型的好开始。我是一个新手，我想从设计这样的东西的人那里得到一些建议或想法。
我正在设计膳食计划应用程序。至于架构，我希望它是基于微服务的应用程序。
服务往往专注于执行而非执行。出版食谱是一个工作流程，用餐计划是另一个工作程序，等等
服务业的一个重要理念是它们应该是自主的。理解自主性有很多不同的方法，但我觉得有帮助的是考虑我们将数据从生产者复制到消费者，这样即使生产者不在，消费者也可以继续做有用的工作。
例如，膳食计划需要一本已出版的食谱。但它不一定需要今天的食谱——一本昨天的食谱就可以了。如果我们有一些异步消息传递，将信息的副本从一个服务传递到另一个服务，我们就可以实现这一点。
然而，我不知道如何切片域来识别有界上下文，这些上下文将是微服务。
是的，这是最困难的部分，尤其是当你在该领域没有足够的经验来了解不同的流程是什么，它们共享哪些实时数据，共享哪些过时数据，等等
好消息是，如果你还不知道答案，那可能是因为你现在需要处理的信息量足够小，你可以一起处理。换言之，首先将重点放在将域模型部署在一个整体中，并在其中的自主模块的边界上迭代——特别注意哪些进程需要共享相同数据的实时副本，哪些进程可以使用过时的数据副本。
设计持久性模型，使特性永远不需要在别人的表中查找(信息是复制的，而不是共享的(。确保模块之间的通信满足位置透明性，这样将组件移动到其他地方就不会破坏世界。