プロジェクトのファイル構成を修正 #58

mochi-yu · 2023-10-04T09:00:02Z

概要

プロジェクトのファイル構成を修正する
これにより、特にロジック・データソース・表示の処理を分ける

実装

以下のような一方向のみの参照となった
- /cmd => /service => /gateway => entity
gatewayにてinterfaceを実装したことで、容易にプログラム上でAISourceを変更可能になった

cocoide · 2023-10-05T02:58:22Z

[ディレクトリの命名や構成に関して]
・domain serviceと混同するから serive→usecaseの方がいいかな
・AISourceは直感的な命名ではない (Sourceはどの文脈のSourceだろ)
→ CommitMessageServiceとかでいいんじゃないのかな
・Interfaceをファイル毎に分けるのなら、packgeで分けた方がいい
(元々、開発効率を優先して同じファイルに書いてた)
このPRが参考になるかなと思うんだけど、gateway層は技術的な関心毎をまとめる(DIをする)層だと元々考えていた。
→ domainディレクトリにentityとservice層をおくとより依存関係の方向がわかりやすくなっていいのかもしれない。
gateway→serivceにDIして
依存関係は
usecase→service→entityになるイメージ

cocoide · 2023-10-05T03:06:36Z

cmd/suggest.go

-	case int(entity.WrapServer):
-		gi = gateway.NewGrpcServeGateway()
-	default:
-		gi = gateway.NewGrpcServeGateway()


コンストラクタ関数 (New〇〇~)はcmdとかのエントリポイントで呼んで欲しい
色々なところで呼び出したらレイアードアーキテクチャの意味がなくなりそう

自分の中のレイヤードアーキテクチャーの目的は、プログラムの責務の分離だけどそれで同じですかね？

この変更の意図は、APIの接続先を選択するロジックを、コマンドの表示周りの処理と分離すること。
cmdディレクトリはCUIの表示とか、操作とかに関する処理だけにとどめたい。どのAPIにアクセスするかの選択は表示とかとは無関係で、cmdディレクトリ内のプログラムでは面倒を見ないようにしたい。

コンストラクタ関数は一箇所にまとめて保守性をあげたかったのが目的。
構造体の中に、該当のサービスを入れたら済む話なのかなと思った。

レイヤードアーキテクチャの目的は文脈
次第だと思うけど、リファクタしても影響範囲を出にくくするのと可読性を上げる事だと思う。

保守性を上げることは、処理をまとめて同じところに書くよりも、各プログラムの責務を明確に分けることで生まれると僕は思うけど。
CLI上での表示をいじりたければ全てcmd\suggest.goを見る。万が一他の部分を変えたとしても、表示以外に影響を及ぼさない。中の処理を変えたければinternal\service\suggest_cmd.goを見る。というのが保守性を高めることじゃないですかね？

「リファクタしても影響範囲を出にくくするのと可読性を上げる事」は、全てのアーキテクチャが考えられている目的で、中でもレイヤードアーキテクチャの目的は、レイヤごとに責務を分けて、他のレイヤの役割を混ぜないことじゃないですかね。

コンストラクタ関数をエントリポイントでまとめた方が依存関係が全部わかって保守性が上がるって意味でいいたかった。
今回は、cmdが実質インターフェースだから特殊だけど。
そこはNewContainerとかでDIだけ別パッケージに切り出すとかで対処できそうかも。

コンストラクタ関数をまとめるのは、まとめるのが目的でなくコード規約てきなものだとイメージしてた。

レイヤ責務を分ける目的はどんな事だと考えてる？

cocoide · 2023-10-05T03:08:14Z

internal/service/file_diff_service.go

 }

-func (ps fileDiffService) CreateFileDiffStr() (string, error) {


この関数は他のUsecase (分割コミットとか)で使って共通化するから
上層のDomain Seriviceに移行したほうがいいかな
(共通化するタイミングで大丈夫なのかなとも思いつつ)

これ、変数名とかを変えただけだよ。
基本domain serviceはusecaseより下層かと思うけど、上層に移行というのは何を想定してた？

たしかに、下層だな。すまん
クリーンアーキテクチャの図を想像していい間違えた。

cocoide · 2023-10-05T03:09:22Z

internal/entity/config.go

+		return err
+	}
+
+	switch configIndex {


マジックナンバーはハードコーディングしないで
iotaとかでenum化した方が見やすいかも

main.go

mochi-yu · 2023-10-05T12:05:44Z

@cocoide

・domain serviceと混同するから serive→usecaseの方がいいかな

これは変更します。

・AISourceは直感的な命名ではない (Sourceはどの文脈のSourceだろ)

変更しても良いけど、ここはservice（明示的に書くならapplication service）ではないので、するならしたのと併せてCommitMessageRepositoryとかにしたい。

・Interfaceをファイル毎に分けるのなら、packgeで分けた方がいい

ごめんこれが何を言いたいのかよく理解できていないわ。
自分の中でのgatewayディレクトリは、repository層のイメージ。変更が分かりにくくなるかと思って名前変えなかったけど、変えて良いなら丸々repositoryに変更したい。この中には外部リソースにアクセスする処理を書きたい。それ以外のファイル変更情報の変更とかは上層のservice(usecase)層の中で処理したい。

あと、domainService作るならentity層の中かと思うよ。

cocoide · 2023-10-05T12:24:15Z

@cocoide

・domain serviceと混同するから serive→usecaseの方がいいかな

これは変更します。

・AISourceは直感的な命名ではない (Sourceはどの文脈のSourceだろ)

変更しても良いけど、ここはservice（明示的に書くならapplication service）ではないので、するならしたのと併せてCommitMessageRepositoryとかにしたい。

・Interfaceをファイル毎に分けるのなら、packgeで分けた方がいい

ごめんこれが何を言いたいのかよく理解できていないわ。

自分の中でのgatewayディレクトリは、repository層のイメージ。変更が分かりにくくなるかと思って名前変えなかったけど、変えて良いなら丸々repositoryに変更したい。この中には外部リソースにアクセスする処理を書きたい。それ以外のファイル変更情報の変更とかは上層のservice(usecase)層の中で処理したい。

あと、domainService作るならentity層の中かと思うよ。

クリーンアーキの文脈でたしかにgatewayはrepositoryと言われることはあるからgatewayでない方がいいかもね。　
(infraとかでも、今のインターン先ではgatewayがインフラ層として扱われてたのにバイアイスかかってた)

entityの中にserviceを入れるのはどこがソースだろ？そうした方がいい理由は何だと思う？

domainにまとめたかったのは、そこに具体的な実装がないつまり、そこを上位のレイヤーだと示したいだけで、無駄に層を深くするのはやる必要はないと思う。

仮にgatewayがrepositoryなら、そこに具体的な実装を置くのはどうだと思う？

repositoryはdbアクセスを抽象化する文脈で使われるからクライアント側で使うのは微妙かも。
reactでレポジトリパターンは使わんくない？

mochi-yu added 7 commits October 4, 2023 15:14

refactor: docコマンドのコードをリファクタ

cc99bd9

refactor: 設定の保存処理を、表示機能から分離

a833572

fix: config.yamlの挙動を修正

6385fd2

fix: モデルの名前をsuggestModelに変更

c27f677

refactor: コミットメッセージの作成処理を、suggest_cmd_serviceとして切り分け

378104d

doc: コメントを追加

be69e70

refactor: コミットを実行する処理をsuggest_cmd_serviceに移植

cf05d15

mochi-yu self-assigned this Oct 4, 2023

cocoide reviewed Oct 5, 2023

View reviewed changes

mochi-yu assigned cocoide and unassigned cocoide Oct 11, 2023

cocoide merged commit 2e5262f into main Nov 6, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

プロジェクトのファイル構成を修正 #58

プロジェクトのファイル構成を修正 #58

mochi-yu commented Oct 4, 2023

cocoide commented Oct 5, 2023 •

edited

Loading

cocoide Oct 5, 2023

mochi-yu Oct 5, 2023

cocoide Oct 5, 2023

mochi-yu Oct 5, 2023

cocoide Oct 5, 2023 •

edited

Loading

cocoide Oct 5, 2023 •

edited

Loading

mochi-yu Oct 5, 2023

cocoide Oct 5, 2023

cocoide Oct 5, 2023 •

edited

Loading

mochi-yu commented Oct 5, 2023 •

edited

Loading

cocoide commented Oct 5, 2023 •

edited

Loading

		}

		func (ps fileDiffService) CreateFileDiffStr() (string, error) {

プロジェクトのファイル構成を修正 #58

プロジェクトのファイル構成を修正 #58

Conversation

mochi-yu commented Oct 4, 2023

概要

実装

cocoide commented Oct 5, 2023 • edited Loading

cocoide Oct 5, 2023

Choose a reason for hiding this comment

mochi-yu Oct 5, 2023

Choose a reason for hiding this comment

cocoide Oct 5, 2023

Choose a reason for hiding this comment

mochi-yu Oct 5, 2023

Choose a reason for hiding this comment

cocoide Oct 5, 2023 • edited Loading

Choose a reason for hiding this comment

cocoide Oct 5, 2023 • edited Loading

Choose a reason for hiding this comment

mochi-yu Oct 5, 2023

Choose a reason for hiding this comment

cocoide Oct 5, 2023

Choose a reason for hiding this comment

cocoide Oct 5, 2023 • edited Loading

Choose a reason for hiding this comment

mochi-yu commented Oct 5, 2023 • edited Loading

cocoide commented Oct 5, 2023 • edited Loading

cocoide commented Oct 5, 2023 •

edited

Loading

cocoide Oct 5, 2023 •

edited

Loading

cocoide Oct 5, 2023 •

edited

Loading

cocoide Oct 5, 2023 •

edited

Loading

mochi-yu commented Oct 5, 2023 •

edited

Loading

cocoide commented Oct 5, 2023 •

edited

Loading