みんなの洋楽ランキングを一年ちょい運用してみて、ある程度それなりの設計をしてるので書き溜めてみる
一応ドメイン駆動設計に基づいて作ってる気がするのですが、そこで疲弊するのが辛いからわりかし適当、というか設計わかりません。個人サービスだと開発に関わる人間が基本一人なのである程度複雑でも対応出来るし、複雑な設計してもサービスを展開するスピードが遅くなるだけなのであえてある程度適当にしてるって言う意図があります(何も考えたくないだけ
構成は
サーバー: centos系
サーバーサイド: ASP.NET Core
フロント:react
フレームワーク:MVC
Dependency Injection
Repository
データの永続化を担うとこ。要はデータアクセスの場所。複雑なクエリはアプリケーション側の都合だと思ってるから本当に単純なデータを引っ張ってくるとこ。ここはDapper早いしLinq強いから出来ることだと思う。インピーダンスミスマッチとか気にせずSQLゴリゴリに書いてる。
Model
スキーマと全く同じ構成のクラス群。Dapperというライブラリを使っていて、複雑なエンティティ(集約)を作ると辛くなるのでテーブルとクラスが一対一になっている。多分C#だったらこれはあるんじゃないかな?
ViewModel
UIにゴリゴリ依存したクラス群。Viewsと対になってる。
Middleware
.NET CoreではDIするためのインスタンスをStartupってところで作るのですが、ゴリゴリにでかくなるのでちょっと分けちゃったりしたりするとこ。一般的にはinfrastructureって呼ばれるとこかな
ResponseModel
react用のREST APIがいくつかあってそのレスポンスの型定義。名前とか終わってる気がするけど「ビューモデル」があるからオッケーってノリで
Extensions
C#には拡張メソッドって言う天才的なものがあって型にオリジナールのメソッドを作れる。日付変換などアプリケーションの仕様的なものはここに詰められる。ほかの言語だとfunctionとかかな?(その名前も大概だけど)
Constant
定数置き場。普通はDomainとかなのかな?
Attribute
CustomAttributeの置き場。
Manager
名前微妙ですが、「外部との連携するために独立して動くもの」って感じのやつが入ってる。Twitterライブラリのラッパーだったりアナリティクスラッパー、メール送信等々。azure functionから使ったりwebサービスから使ったりと共通して使えてかつ依存しないものを詰め込んだもの。実際は別リポジトリで管理してsubmoduleして使ってる。よくありがちな抽象的な名前にしたら何でも屋になった的な感じ。HTTP Clientはrepositryだろと思うけど、アプリケーションデータの核となる部分と認識しちゃってたからデータアクセスやらに限定してた。
Service
ビューモデルやResponseModelを作るところ。アプリケーションがどういった振る舞いをするかはここみれば大丈夫だろうってところ。でかくなりがちでいろいろやり過ぎてる感満載。複雑のデータの取得をしないように心掛けてるからどうしてモデルの整形などはここに集中してしまう。規模に応じてアプリケーションサービスとドメインサービスを分ける予定。
library
自前のライブラリ群。自作してだっぱーのらっぱーとか入れてる
Styles
共通して使うスタイル、画面特有のスタイルとざっくり分けてる。ここら辺はほんと適当。画面特有のスタイルなんてほとんどないから共通系が肥大化して「あれ?意味なくね?」ってなってる。
Images
画像とか思いっきりまとめてる。そこまで数が無かったんだけどちょっと増えてきたから検討中
Test
まんまテスト。ちょーざっくりしたインテグレーションテストしかやってないけど
運用してみて
あいまいな名前(Service、Managerなど)は何でも屋になりやすいし、ゴミ箱(なんでも詰められる)になりがち。設計は抽象度が保たれた方が良いと思うけど、言語特有の分け方した方が、言語に精通してる人にはわかりやすい気がする。デカくなったら分ける、これでいいと思う。DIは最強、このおかげである程度依存が切り離せてるから素敵。でもどこでもDIはよくない。どうしてもN+1を考慮した作りをすると複雑で分かりにくいからここは課題。やっぱドメインサービスつくるかぁ。図を作った方が良いなこれは