Clean Architecture中用例层的边界、定义及相关技术疑问

一、实体的核心定位 #

我认为Entity承载核心属性、方法与校验逻辑。例如User Entity包含姓名、DoB（出生日期）、邮箱、是否验证等项目核心属性——不同项目对核心属性的定义不同，有的需要phone number（手机号），有的则无需手机号但需要邮寄地址。

用例层依赖于实体层，我认为用例比实体更灵活，可基于单个或多个实体编写额外逻辑与计算，但存在以下疑问：

二、用例层的具体疑问 #

• 用例能否从实体属性生成派生值（如通过DoB计算Age）并持久化到存储中，还是这些派生值必须预先定义在User Entity类中？
• 用例层是否必须依赖实体？能否存在仅执行sum(a,b)这类逻辑、可选择是否持久化结果的用例？
• 将实体属性持久化到数据库后，再次检索时是否需要重新校验？这是否属于冗余操作并影响性能？

三、用例的定义与边界核心困惑 #

我最大的疑问是：用例的定义与边界到底是什么？用例是否需要做到对输入来源与输出受众无关？这是否仅指依赖倒置原则下不绑定具体框架（如切换Express、Koa无需重写核心逻辑），还是要适配更广泛的场景（如同时适配终端应用与Web API服务）？

若为后者，我存在困惑：用例需与输入输出介质无关，但输出格式却往往适配特定介质。例如设计RESTful API时，getUserPosts(userId, limit, offset)的输出格式更适合Web API消费者——这在我看来属于特定应用的业务逻辑，很难复用给需要更详细响应的本地终端应用。

我认为用例的优势在于切换同类型应用的框架（如REST API切换Express/Koa，终端应用切换Node.js/Bun），而非跨场景复用。若要实现跨场景复用，是否需要设计更通用的用例（如增加sideloadingConfig、expandedConfig、format等配置参数），还是拆分多个专用用例（如getUserPostsWebServices、getUserPostsForLocal）？后者更合理，因为每个用例有独立约束，且不绑定具体框架，但我缺乏经验，希望得到澄清。

内容的提问来源于stack exchange，提问作者cozycoder