用途：该技能用于设计 Python 应用的架构分层，遵循函数式核心／命令式外壳模式、领域驱动设计（DDD）与类型安全数据建模，适合在划分应用层次、把纯业务逻辑与副作用分离时参考。
核心原则：将纯业务逻辑与副作用分离。函数式核心由纯函数构成，承载业务逻辑且不做 IO；命令式外壳负责协调外部依赖、处理副作用。
分层架构：依赖自下而上传导，路径为 Router/Handler → Service → Repository → Entity → Database，每层只依赖其下层。职责上，Entity 负责领域模型、校验、业务规则和数据转换（fromRequest、toRecord、toResponse）；Repository 是抽象存储接口，返回领域实体；Service 负责业务工作流，编排实体与仓储；Router/Handler 处理 HTTP 并委派给 Service。
领域模型：实体具有身份与封装行为，示例中 Order 用 dataclass 定义 id、customer_id、total、status，并封装 apply_discount 等业务规则及 from_request、to_response 转换方法。值对象不可变、无身份，示例中 Money 使用 @dataclass(frozen=True)，在 add 时校验货币一致。DDD 的聚合、限界上下文与领域服务见 references/ddd.md。
仓储模式：用抽象接口隐藏存储，OrderRepository 以 ABC 声明 get、save；PostgresOrderRepository 等具体实现负责在记录与领域实体间转换并提交。
数据建模：dataclasses 用于领域模型和内部逻辑；Pydantic 用于 API 边界（校验、JSON schema、OpenAPI）；实体转换方法包括 from_request、to_response、from_record、to_record。详见 references/data-modeling.md。
最佳实践：优先纯函数；业务规则封装在实体内；通过仓储抽象隐藏存储细节；在边界处校验；值对象始终使用 frozen=True；单一职责；依赖抽象而非实现。
反模式：贫血领域模型、事务脚本、泄漏抽象、上帝对象、关注点混杂（业务逻辑直接调用 IO）。
限制：资料未提供安装命令、平台、价格、性能或效果数据，暂未提供。