从自己的 Go 项目转去读 ArdanLabs 和 Memos

为什么读开源项目

突然想到我的这个本来就是 vibe coding 的项目，可能在代码质量上面不足，应该直接学习开源的被大众认可的高质量的项目，看他们的工程化和代码。

ArdanLabs Service：跟 MemoFlow 的架构比较

这个项目是 GPT 推荐的一个项目，它的工程化做得比较好，也是领域驱动设计的。

这和我的 MemoFlow 项目在架构设计上有相通之处，但我的设计像是把它“旋转了 90 度”：

• 我的架构（MemoFlow）： 整体上先按照业务进行水平拆分。顶部是按照业务拆分的包（packages），比如 goal、task、reminder 等。在每个包内部，再按照不同的架构层级进行拆分，例如每个 package 内部包含 domain（领域层）、application（应用层）、infrastructure（基础设施层）和接口层。 • 该项目的架构： 先整体进行垂直分层（将接口、业务、基础设施作为顶层目录），再在内部按领域业务进行内聚。

顺便提一下，在这次学习和询问的过程中，我突然意识到一件事：DDD 架构中的 Presentation（展示层）并不是我之前理解的前端那种页面展示，而是更类似于接口不同的暴露形式，比如 CLI、RESTful 接口或 gRPC 接口，类似我现在搞的接口层/Router 层。

总之，它的整体架构和 MemoFlow 比较相似，不过里面有一些工程细节需要进一步学习。

印象比较深的细节

我觉得它的路由层和接口层做得很好。它封装了一个 HandleFunc 方法，直接将请求方法、路由和对应的 Handler 传进去，包装得非常优雅。这样一来，请求方法、路由路径以及需要调用的 Handler，还有前面需要经过哪些中间件处理，都表达得非常清晰。

这里有一个比较特殊、也是我第一次见到的设计，就是它的仓储层（Store）分为了两层：一层缓存层，一层真实的数据库。对于业务层来讲，它并不需要知道缓存层的存在，调用时就像正常使用一样，通过传入的依赖调用 Store 里的 Create 等方法。但在初始化封装时，它是先传入基础数据库实例，创建一个缓存层，再把缓存层传给 Service。所以对 Service 来说，它当前使用的 Store 其实是一层缓存层。在缓存层里，它会先尝试读取缓存数据，有的话直接返回，没有再去查真实的数据库。

Memos 的契约层

这个项目也是一个 GitHub 上面开源的高星大项目，基于 React 和 Go，并且它有了比较丰富的更新迭代的经验吧。 它是更接近前端 React 加上后端 Go 的架构。

这有点类似我的 MemoFlow 项目中的 Contract（契约层），但它做得更多：我的契约层只是确保前后端的定义统一，而它不仅确保了定义统一，还把中间的 Transport 层也给封装了