V2EX › tangkikodo 的所有回复 › 第 1 页 / 共 4 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4

❮

❯

2 天前

回复了 tangkikodo 创建的主题 › Python › 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论

@pf94 Data -> Repo -> Service -> Controller

是的，这个是经典做法，毕竟实现单向依赖的前提就是合理的分层

我的这个方法是借助 dataloader 这样的工具将 repo 层的能力提高，controller 中组合数据的过程更加流畅

2 天前

回复了 tangkikodo 创建的主题 › Python › 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论

@dearmymy 谢谢

2 天前

回复了 tangkikodo 创建的主题 › Python › 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论

@ruanimal 分离业务复杂度和代码复杂度，因为业务软件的核心资产是业务模型和用例。很多时候业务模型和代码实现互相侵入，依赖关系错综复杂，导致业务迭代困难

2 天前

回复了 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.

2025 年 11 月 10 日

回复了 tangkikodo 创建的主题 › 分享创造 › fastapi-voyager: 一个基于 fastapi 的业务关系可视化平台

@xhawk 嗯，明白了。我之前也想做 service 调用的分析，但是复杂度太高了，后来用 pydantic-resolve 实现了某种平替，一个 service 返回的类型，来间接代表这个 service 。因为后端很多场景本质都是数据的组合，如果数据类型是清晰的，那么通过什么具体获取方式反而不是这么重要了。

比如 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 内依赖关系

@yb2313 fastapi 现在迭代进度明显减慢了，确实相比之下 litestar 功能相当丰富

回头如果有需要，去移植个 litestar-router-viz ～

2025 年 10 月 3 日

回复了 tangkikodo 创建的主题 › Python › fastapi-router-viz, 可视化你的 API 内依赖关系

支持生成 dot 文件，转换成 mermaid 语法的话要找一些 dot2mermaid 的小工具

2025 年 7 月 15 日

回复了 tangkikodo 创建的主题 › Python › Resolver 模式，一种比 GraphQL 适用于 BFF 的新选择

@pluswu1986 是的，最后苦果还得自己吞。。

2025 年 6 月 17 日

回复了 tangkikodo 创建的主题 › Python › Resolver 模式，一种比 GraphQL 适用于 BFF 的新选择

@seansong 和 GraphQL 那些技术栈和框架相比算不了太工程化吧

现在 pydantic v2 的性能也足够强了，pydantic-resolve 的行为类似于给字段提供数据获取和修改的 hook 方法

就这么两个 “规则”

2024 年 7 月 25 日

回复了 Irisxx 创建的主题 › 程序员 › 一个接口引发的前后端处理数据标准的思考

后端组合，大概率后端自己也不喜欢拼数据所以想偷懒了。

https://github.com/allmonday/pydantic-resolve-demo 如果是 python 这边的话，这种需求 pydantic-resolve 一把梭直接就能组合好。

2024 年 7 月 11 日

回复了 solaris2022 创建的主题 › React › 各位是如何写单元测试的，如何保证单元测试覆盖率

怎么写（单元）测试？

要从可测的思考方式来书写代码，才有“可能”写测试

在写实现之前，或者实现之后里面套上测试，否则久了就不会写了

要懂得常用的 mock 第三方接口的方法，会构造数据整合查询一起测试

知道哪些应该写，哪些没必要

知道怎么结合 use case 来写

知道怎么结合 hook 在 commit 之前强制测试跑通

知道怎么划分出合适的 service 层并覆盖测试，避免在应用层写无聊的测试

想到更多了在补充。

关于只在 service 覆盖测试，应用利用继承和组合避免测试，可以参考
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/services/sprint/readme-cn.md

2024 年 7 月 8 日

回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向

@fescover
是的生态的优势非常重要

2024 年 7 月 8 日

回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向

@justdoit123

gql 的另一个问题是数据结构关联按照什么模式来组织

如果按照业务模型的方式组织，那么面向具体的展示层，很多查到的关联结构要在 UI 上重新做调整。

如果按照 UI 的需求来组织，那么这个 gql 写起来就很没劲了。。变成了大号 rest

2024 年 7 月 8 日

回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向

@ilvsxk

bff 如果不是前端去维护的话，感觉这个 bff 的组织划分就有问题哎。。（比如现在 node 就是 bff 的绝对优势语言（虽然我不太喜欢

本质上就是让前端自己组合出所需的数据，避免不必要的组合逻辑侵入到前端展示层。

2024 年 7 月 8 日

回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向

@justdoit123 完全同意

我觉得这个工具其实不是给前后端对接用的，围绕着他的 DSL ，明明语言原生就有的类型，还得顺着它定义一套类型。啰嗦了。

臃肿的请求，前端自己通过查询串联起来许多服务，导致后端要调整的时候非常被动。

本来能用一个 client.load_xxx_data 搞定的事情，还得在前端维护一大串查询，这是对迭代很不友好的~

1 2 3 4

❮

❯