用途：在选定目录与声明之前，先设计 Encore 应用的逻辑架构。同一套架构推理适用于 Encore.ts 与 Encore.go；语言相关的具体实现应改用 encore-service 或 encore-go-service。
主要能力：读取现有代码与 Encore 应用模型，识别用户与系统操作、API、cron 任务、Pub/Sub 处理器、数据模型及其变更代码、基础设施资源、现有同步调用与事件流，以及失败、扩缩容、部署和安全要求。除非需求要求重新定义，否则保留既有应用概念。
服务与进程：Encore 服务是代码与 API 边界，不是固定部署单元。平台可按环境配置把所有服务跑在一个进程，或每个服务单独进程，无需改代码。服务边界表达职责，进程分配用于调整隔离与扩缩容。
服务边界：新应用默认先建一个服务，除非已知稳定边界；内部用模块、目录或 Go 子包组织。内聚业务能力、失败隔离、独立扩缩容或部署、更小安全接口、已有外部系统接缝，可支持拆分。需权衡网络失败、跨服务协调、分布式一致性与接口维护成本。避免按处理器、业务逻辑、数据库访问等技术分层建服务；应暴露 ReserveInventory 这类能力操作。
数据归属：每个数据模型、业务规则与 schema 变更由一个服务负责。Encore 支持通过 SQLDatabase.named（TypeScript）和 sqldb.Named（Go）共享数据库访问，用于报表、增量迁移等场景，但需先定义迁移归属与写权限。Encore 不要求每服务一库。
通信：调用方需结果、需报告成败或某服务拥有该能力时用类型化服务 API；无需等待、多消费者独立反应或消费者重试不应重复原始请求时用 Pub/Sub，并考虑最终一致性、幂等。数据库变更与事件发布需一致时，Encore.go 提供事务性 Pub/Sub outbox，其他情况需应用自定一致性机制。
接口与授权：操作分为公开、已认证、私有；内部能力操作保持私有。认证与跨域策略放在网关，具体能力或记录的授权决策留在拥有它的服务。
组织与演进：Encore 服务不可嵌套，大量相关服务可放入 system 目录，system 仅组织源码，不是 Encore 资源或部署单元。拆分时识别一起移动的操作与数据，新增服务，用 API 或事件替换直接调用，定义过渡期数据归属，并在 Encore Flow 中检查模型、测试跨边界调用。推荐架构时应列出服务、职责、拥有资源与通信路径，说明拆分理由与一致性/失败权衡，优先满足需求的最小架构。完整指南与语言示例见 App Structure。