tangkikodo 最近的时间轴更新 tangkikodo 最近的时间轴更新 | tangkikodoV2EX 第 291907 号会员，加入于 2018-02-13 14:40:00 +08:00 |
| 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论 Python tangkikodo 11 天前 最后回复来自 chaoshui | 12 |
| FastAPI Voyager, 一次对 API 结构可视化的尝试 程序员 tangkikodo 2025 年 12 月 3 日 |
| fastapi-voyager: 一个基于 fastapi 的业务关系可视化平台 分享创造 tangkikodo 2025 年 11 月 10 日 最后回复来自 tangkikodo | 7 |
| fastapi-router-viz, 可视化你的 API 内依赖关系 Python tangkikodo 2025 年 11 月 6 日 最后回复来自 workshop | 8 |
| Resolver 模式，一种比 GraphQL 适用于 BFF 的新选择 1 Python tangkikodo 2025 年 7 月 15 日 最后回复来自 tangkikodo | 4 |
| 使用 pydantic-resolve 简化 ER 模型到视图模型的流程 Python tangkikodo 2025 年 3 月 30 日 |
| pydantic-resolve，一个小巧的数据组装工具库，通过声明式描述数据，可减少 50% 以上的组装代码 程序员 tangkikodo 2024 年 11 月 22 日 |
| 上次聊前后端分工还是有点空洞， 这次来贴一个 demo 1 Python tangkikodo 2024 年 7 月 25 日 |
| 从前后端分工的利弊谈起，聊聊这套分工的未来方向 1 程序员 tangkikodo 2025 年 8 月 23 日 最后回复来自 mouyase | 33 |
| 从 restful 到 graphql， 从 rpc 到 pydantic-resolve， 谈谈前后端紧耦合项目接口的（可能）演进方向 程序员 tangkikodo 2024 年 8 月 7 日 最后回复来自 shujuliuer | 4 |
tangkikodo 最近回复了
13 天前 回复了 tangkikodo 创建的主题 Python 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论 |
@pf94 Data -> Repo -> Service -> Controller
是的，这个是经典做法， 毕竟实现单向依赖的前提就是合理的分层
我的这个方法是借助 dataloader 这样的工具将 repo 层的能力提高，controller 中组合数据的过程更加流畅
是的，这个是经典做法， 毕竟实现单向依赖的前提就是合理的分层
我的这个方法是借助 dataloader 这样的工具将 repo 层的能力提高，controller 中组合数据的过程更加流畅
13 天前 回复了 tangkikodo 创建的主题 Python 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论 |
@dearmymy 谢谢
13 天前 回复了 tangkikodo 创建的主题 Python 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论 |
@ruanimal 分离业务复杂度和代码复杂度， 因为业务软件的核心资产是业务模型和用例。 很多时候业务模型和代码实现互相侵入， 依赖关系错综复杂， 导致业务迭代困难
13 天前 回复了 tangkikodo 创建的主题 Python 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论 |
@llsquaer 中间表在业务描述的时候是不需要被产品等人员知晓的， 他们只要知道 voyager 从 A -> B 的关系， 如果用 DB ERD 的话， 这个中间表（技术实现细节）是会被展示出来的。
扯到中间表是为了引入一些案例来说明业务模型和 db 模型不是完全一一对应的， 中间表数据具体的技术实现， 比如还能替换成其他做法， 比如（不严谨） A 中存放 list of b_ids ，B 中存放 list of a_ids.
扯到中间表是为了引入一些案例来说明业务模型和 db 模型不是完全一一对应的， 中间表数据具体的技术实现， 比如还能替换成其他做法， 比如（不严谨） A 中存放 list of b_ids ，B 中存放 list of a_ids.
2025 年 11 月 10 日 回复了 tangkikodo 创建的主题 分享创造 fastapi-voyager: 一个基于 fastapi 的业务关系可视化平台 |
@xhawk 嗯，明白了。 我之前也想做 service 调用的分析， 但是复杂度太高了， 后来用 pydantic-resolve 实现了某种平替， 一个 service 返回的类型， 来间接代表这个 service 。 因为后端很多场景本质都是数据的组合， 如果数据类型是清晰的， 那么通过什么具体获取方式反而不是这么重要了。
比如 Project 类型 通过 load_project 来获取， 那么我只要知晓组合的是 Project 或者 subset of Project ， 那我其实也间接知道了调用链条。
仅供参考~
比如 Project 类型 通过 load_project 来获取， 那么我只要知晓组合的是 Project 或者 subset of Project ， 那我其实也间接知道了调用链条。
仅供参考~
2025 年 11 月 9 日 回复了 tangkikodo 创建的主题 分享创造 fastapi-voyager: 一个基于 fastapi 的业务关系可视化平台 |
@xhawk 有兴趣的话可以也试试 pydantic-resolve, voyager 其实是为它量身定做的～
2025 年 11 月 9 日 回复了 tangkikodo 创建的主题 分享创造 fastapi-voyager: 一个基于 fastapi 的业务关系可视化平台 |
@xhawk 不客气～～
2025 年 10 月 4 日 回复了 tangkikodo 创建的主题 Python fastapi-router-viz, 可视化你的 API 内依赖关系 |
改了个名字：fastapi-voyager
2025 年 10 月 4 日 回复了 tangkikodo 创建的主题 Python fastapi-router-viz, 可视化你的 API 内依赖关系 |
@3085570450tt 确实， 当局者迷了
2025 年 10 月 3 日 回复了 tangkikodo 创建的主题 Python fastapi-router-viz, 可视化你的 API 内依赖关系 |
Select Language