tekitoumemo’s diary

思ったことを書くだけ。長文版Twitter

個人サービスでの設計について

みんなの洋楽ランキングを一年ちょい運用してみて、ある程度それなりの設計をしてるので書き溜めてみる

一応ドメイン駆動設計に基づいて作ってる気がするのですが、そこで疲弊するのが辛いからわりかし適当、というか設計わかりません。個人サービスだと開発に関わる人間が基本一人なのである程度複雑でも対応出来るし、複雑な設計してもサービスを展開するスピードが遅くなるだけなのであえてある程度適当にしてるって言う意図があります(何も考えたくないだけ

構成は

サーバー: centos
サーバーサイド: ASP.NET Core
フロント:react
フレームワーク:MVC

Controller

リクエストをアプリケーションサービスに渡す、返すだけ。まじなんもしてない。たまにリクエストヘッダーとかセッションとかここで使う

Dependency Injection

ASP.NET CoreからDIアーキテクチャが導入されたので全てのクラスをインターフェースを介して使ってる。

Repository

データの永続化を担うとこ。要はデータアクセスの場所。複雑なクエリはアプリケーション側の都合だと思ってるから本当に単純なデータを引っ張ってくるとこ。ここはDapper早いしLinq強いから出来ることだと思う。インピーダンスミスマッチとか気にせずSQLゴリゴリに書いてる。

Model

スキーマと全く同じ構成のクラス群。Dapperというライブラリを使っていて、複雑なエンティティ(集約)を作ると辛くなるのでテーブルとクラスが一対一になっている。多分C#だったらこれはあるんじゃないかな?

ViewModel

UIにゴリゴリ依存したクラス群。Viewsと対になってる。

Middleware

.NET CoreではDIするためのインスタンスをStartupってところで作るのですが、ゴリゴリにでかくなるのでちょっと分けちゃったりしたりするとこ。一般的にはinfrastructureって呼ばれるとこかな

Views

ビューのレンダリングはrazorって言うASP.NETレンダリングエンジンってやってる。そのHTMLの置き場。

ResponseModel

react用のREST APIがいくつかあってそのレスポンスの型定義。名前とか終わってる気がするけど「ビューモデル」があるからオッケーってノリで

Extensions

C#には拡張メソッドって言う天才的なものがあって型にオリジナールのメソッドを作れる。日付変換などアプリケーションの仕様的なものはここに詰められる。ほかの言語だとfunctionとかかな?(その名前も大概だけど)

Constant

定数置き場。普通はDomainとかなのかな?

ClientApp

reactコンポーネント置き場。dotnet cliで生成された名前。

Attribute

CustomAttributeの置き場。

Manager

名前微妙ですが、「外部との連携するために独立して動くもの」って感じのやつが入ってる。Twitterライブラリのラッパーだったりアナリティクスラッパー、メール送信等々。azure functionから使ったりwebサービスから使ったりと共通して使えてかつ依存しないものを詰め込んだもの。実際は別リポジトリで管理してsubmoduleして使ってる。よくありがちな抽象的な名前にしたら何でも屋になった的な感じ。HTTP Clientはrepositryだろと思うけど、アプリケーションデータの核となる部分と認識しちゃってたからデータアクセスやらに限定してた。

Service

ビューモデルやResponseModelを作るところ。アプリケーションがどういった振る舞いをするかはここみれば大丈夫だろうってところ。でかくなりがちでいろいろやり過ぎてる感満載。複雑のデータの取得をしないように心掛けてるからどうしてモデルの整形などはここに集中してしまう。規模に応じてアプリケーションサービスとドメインサービスを分ける予定。

library

自前のライブラリ群。自作してだっぱーのらっぱーとか入れてる

Styles

共通して使うスタイル、画面特有のスタイルとざっくり分けてる。ここら辺はほんと適当。画面特有のスタイルなんてほとんどないから共通系が肥大化して「あれ?意味なくね?」ってなってる。

Images

画像とか思いっきりまとめてる。そこまで数が無かったんだけどちょっと増えてきたから検討中

db

ddldmlがあるとこ。C#に良いマイグレーションツールがない。ほんとdb系は弱いなぁという印象。

Test

まんまテスト。ちょーざっくりしたインテグレーションテストしかやってないけど

運用してみて

あいまいな名前(Service、Managerなど)は何でも屋になりやすいし、ゴミ箱(なんでも詰められる)になりがち。設計は抽象度が保たれた方が良いと思うけど、言語特有の分け方した方が、言語に精通してる人にはわかりやすい気がする。デカくなったら分ける、これでいいと思う。DIは最強、このおかげである程度依存が切り離せてるから素敵。でもどこでもDIはよくない。どうしてもN+1を考慮した作りをすると複雑で分かりにくいからここは課題。やっぱドメインサービスつくるかぁ。図を作った方が良いなこれは