写経:Go言語でつくるREST API開発 2024年版
2 章 API エンドポイントの実装
はまってる 本質ではなさそうなのでTODOということで、次へ
$ swag init -g api/cmd/main.go
2024/10/31 21:36:06 Generate swagger docs....
2024/10/31 21:36:06 Generate general API Info, search dir:./
2024/10/31 21:36:07 ParseComment error in file /home/ubuntu/work/golang-rest-api/internal/controller/system/handler.go :cannot find type definition: Response
3 ドメインの実装
omitemptyって何?
- フィールドが空値のとき、フィールドを省略する
- 空値 is
- false
- 0
- nil
- 空配列
- 空map
- 空文字(?)
The "omitempty" option specifies that the field should be omitted from the encoding if the field has an empty value, defined as false, 0, a nil pointer, a nil interface value, and any empty array, slice, map, or string.
entity.goってディレクトリの一番上に作るのでいいのかな
え?なんか全然違うところにあるし中身も違うんだが
章ごとにブランチを分けています。
あった
ユースケース?ドメイン?
repository.goにUserServiceRepositoryインターフェイスを書いている。これらのメソッドを持ってないといけない。
type UserServiceRepository interface {
FindUser(ctx context.Context) ([]*User, error)
FindUserById(ctx context.Context, id string) (*User, error)
Save(ctx context.Context, param *User) error
Delete(ctx context.Context, id string) error
}
domain/user/domain_service.goを書いている。
repoどっから出てきた?
type UserDomainService struct {
repo UserServiceRepository
}
func NewUserDomainService(repo UserServiceRepository) *UserDomainService {
return &UserDomainService{repo: repo}
}
内容に関係のないZennへの文句だけど、左ペイン畳みたいな
画面広げたらコードブロックも広げて欲しい
行をラップする機能があることに気がついた
ドメインの実装終わったけどドメインサービスもドメインロジックもリポジトリのなんのことかわからん
4章 ユースケースの実装
なんとなく、1つのユースケースが1つのDBクエリに対応していそうということは分かった
以下わからないこと
- context.Contextとは
- AdminDomainServiceとは
なんか不安になってサンプルコード見たら、2章の段階で特段の解説なく実装されているコードがあったので追加
これ(swagでドキュメント生成するやつ)がうまくいかなかった原因なのでは?
コードブロックに設定されているパスも、必ずしもプロジェクトのルートからのものではなかったようなので修正
これも。user___id
って、ほんとか?
これも。なんで3つも定義してるんだろう?
api/cmd/main.go のコードを見てるんだけど、import文ってこれでいいの?
github.com/o-ga09/GO_TEMPLATE_RESTPI/api/internal/presenter
じゃないの?
バッククォートで囲った文字列は生の文字列リテラル
Pythonの r'foobar'
みたいなことだと思う
userというモデルとその値の値オブジェクトだ
下手なことを言うと燃えるぞ
その下に値オブジェクトのメソッドが続く。
Goのメソッドの書き方は不思議
// 構造体を使った型定義
type user struct {
ID userUUID `json:"id,omitempty"`
...
}
// userUUIDの型定義
type userUUID struct { value string }
// userUUID.valid()の定義
func(v *usreUUID) valid() error {
r := regexp.MustCompile(USER_ID_PATTERN)
matched, _ := r.MatchString(v.value)
if !match {
return INVALID_USER_ID
}
return nil
}
今気がついたけど、user型の定義がZennとGItHubで違う。。。
Zenn
type User struct {
ID UserUUID `json:"id,omitempty"`
Email UserEmail `json:"email,omitempty"`
Password UserPassWord `json:"password,omitempty"`
User_ID UserID `json:"user_id,omitempty"`
FirstName UserFirstName `json:"first_name,omitempty"`
LastName UserLastName `json:"last_name,omitempty"`
Gender UserGender `json:"gender,omitempty"`
BirthDay UserBirthDay `json:"birth_day,omitempty"`
PhoneNumber UserPhoneNumber `json:"phone_number,omitempty"`
PostOfficeNumber PostOfficeNumber `json:"post_office_number,omitempty"`
Pref Pref `json:"pref,omitempty"`
City City `json:"city,omitempty"`
Extra Extra `json:"extra,omitempty"`
}
GitHub
getterというやつ?
5 ドライバーの実装
中断、暗黙の前提が多くて今の私には難しい