<<Go With The Domain>> 笔记

Wild Workouts

一款服务于私人健身房教练和学员的应用

教练可以在有空时安排日程表。
学员可以在提供的可训练日程上预约。

其余功能

1. 管理积分（学员可预约次数）
2. 取消：
    - 如果学员在日程前24小时内取消预约，不能返还扣除的积分
3. 训练日程：
    - 任何人在训练开始前24小时内修改日程，必须由第二个参与者同一（教练或学员）
4. 日历浏览

前端

OpenAPI（Swagger）client，Bootstrap，Vue.js

(OpenAPI-Specification)[https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.0.md]

后端

3 services:

trainer: 对外HTTP，对内gRPC节点，管理教练日程
trainings: 对外HTTP，管理学员训练
users: 对外HTTP，对内gRPC节点，管理积分和用户数据

如果一个服务暴露了两种类型API，每种分别由独立程序提供。

对外HTTP API

从Spring、Symfony、Django或者Express转来的开发者对Go没有统一的HTTP框架会感到非常奇怪，使用任何Go框架都会给项目带来不必要的复杂度和耦合性。作者建议任何Go框架都可以使用，比如chi一个简单的路由足矣（KISS原则）。chi可以提供轻量粘结剂来定义我们需要的API格式，底层使用Go标准http包，所以中间件等工具可以完全适配

所有服务用同种方法运行HTTP，方法可复用。

Chi提供了一系列内建HTTP中间件，不过我们不仅限于这些，所有Go标准库的中间件都可以用。
通过多种解偶的中间件，可以在请求被执行前后做些事情，灵活的定制我们的HTTP服务。

ps: gRPC生态(+gateway)也可以做到~

目标是用Domain-Driven Design,Clean Architecture,CQRS,Event Storming and EventModeling 去解决应用中的问题

gRPC

比起仅仅是前后端共用结构体的OpenAPI，gRPC更加严格，通过gRPC交互的服务很容易达到鲁棒性，当达到每秒数百万的请求量时比REST快10x。其它优点：

基于HTTP/2
多语言
理论上可以直接和前端通信
“Goish”，编译阶段避免了一些定义错误（比起REST参数请求和响应都严格定义)

ps: gRPC是Google的，社区活跃，生态完备。Goish没查出来出处。

为了让gRPC生成的client工作，还需要传递几个额外选项：

授权认证（实现credentials.PerRPCCredentials接口，使用JWT，Header.Payload.Signature）
TLS 加密
服务发现

gRPC在同步对话上有优势，由于Wild Workouts当前章节不需要异步，对于需要异步的需求特征以后章节有。同时可以参考Watermill，它可以便捷构建异步、事件驱动的应用。

Firebase 认证

故意把当前版本的应用做得很难维护和迭代。 "Catastrophes are not a matter of coincidence, but series of unfortunate events" 认证问题在OWASP Top Ten report中排第二严重，不容轻视。

一个简单的解决方案 jwt-go

由于本书的Wild Workouts使用Firebase托管，所以自然使用Firebase的认证。

Domain-Driven Design 精简版

Before sitting to write this chapter, I checked a couple of articles about DDD in Go in Google. I will be brutal here: they are all missing the most critical points making DDD working. If I imagine that I would read these articles without any DDD knowledge, I would not be encouraged to use them in my team. This superficial approach may also be the reason why DDD is still not socialized in the Go community.

ps: 对这个不太理解，Google代码可以提供很好的服务，是不是完全DDD很重要吗？或许是另一种方法论，不好吗？

慢慢走，走的更快

拿测试为例，项目开始时为了快速迭代而跳过写测试，但随着项目增长，你的团队害怕任何变更。最后，你花费的总时间可能会比一开始去写测试用例更多。另一方面，如果项目不严格并且需要快速开发，你可以跳过测试。这是个程序决策。--并不是所有项目都足够复杂，值得使用例如DDD等先进技术。

并没有质量和速度的平衡，如果你希望在长期走的更快，就需要保持高质量

northfun / northfun.github.io