本日の作業
分報に関する設計・実装
🚴 Model・Repository実装
データベース環境の構築
Supabaseのセットアップ
➕ serverをAPI appとして切り出す
prisma・tRPCの導入
そのほか、メモ
サービスロゴやロゴタイポなどのV.I.（Viasal Identity）のFeature-Sliced DesignにおけるComponent設計について
サービスロゴやロゴタイポなどのV.I.（Viasal Identity）が汎用的なただのロゴなのか、サービス（事業）におけるドメインの中で意味のある実体 = Entityなのかが以前からずっとどっちか（内心はEntityと思っているけど）迷うところだった。いい機会なのでFeature-Sliced DesignにおいてこれはどのレイヤーなのかChat GPTに聞いたところ、最初は「再利用性が高い→汎用的であるのでshared」という答えが返ってきた。
この回答を踏まえ、V.I.はサービスのドメインにおいて意味のあるもので、単にUIの部品としてというよりはサービスが何であるかを示すもの。さらにそれを明示することでユーザのメンタルモデルにはサービス名とサービスでできることが紐づけられる（一種のブランディング）もあり、ロジックや直接的な機能性はないがこれらを踏まえるとsharedではなく寧ろentitiesの方が妥当ではないか？また意味のある概念を実態として捉えるならばまさにEntityであると説明して返すと、その側面もあるのでentitiesとして捉える方が良いという回答になった。
ある意味頑固ではないけど、なんかあっさり覆されててさまざまな知識のある新人社員って感じがぴったりだと思った。
core/serverについて
今回のアプリケーションの場合、serverはBackend
まだコード書いてないけどtRPCの手前はDMMF(Domain Modeling Made Functional) で実装される（予定）。
BackendとBFF(FE)=RemixはtRPCでやり取りする。
つまりこれもアプリケーション。
現在のcoreはアプリケーションではなく、ドメインに関するModelやFeature-Sliced Designのentities, featuresが置いてある場所でこれ自体アプリケーションではない。
別にアプリケーションとして切り出した方が良い
express + tRPCとかになる想定
現状はこの構成。serverを外に出した方がいい。
見直し後、apps配下にはcore, api <-- new!!, admin, developersにした。
ただ、この考えだとcoreはappsにいるのがおかしなことになる様な気もしなくも…こうなる方が区切り方としては自然だけどまぁ一旦appsに入れておく。
と思ってcoreにFSDのentitiesを置いてみたら.tsを認識しないエラー…
TypeError: Unknown file extension ".ts" for /Users/tsuyoshihiguchi/develop/mulligan/repositories/front-end/apps/core/src/views/index.ts
packages配下のuiやutilsはうまくいくので同じtsconfigなどにしてみてもうまくいかず。apps配下故に起こってる？過去Next.jsの時はこんなこと起こらなかったのでこれを機会にcoreもpackages配下に移動してみようと思います。てなると、FSDのentitiesやfeaturesをcoreに置く理由がない…。