# 2021/11/07 メンター相談 ###### tags: `メンター相談`,`11月` ## Next.jsの `<Head>` コンポーネントを使用して SEO 対策を行ったことはありますか？ 具体的にどのような対策を行いましたか？ - SEO意識しなければ行けないサービスを作ったことがないので、やったことがない - 企業向けのサービスが多いので、インデックスされたら困る - robots.txtでインデックスしないように指定する - HEADでやったことがある - ページごとにtitleを設定する - twitterのcard imageの設定 (SNS映えを意識) - google analyticsのタグを入れる (共通設定なので_documentにいれる事が多い) - canonicalを設定するためにheadを使った - A?canpaingid=hogehogeなどバリエーションが多くなる場合 - キャンペーンページに流入が分散して、Aにアクセスが集まらない可能性がある - canonical linkを使用することで A?canpaingid=hogehoge などのインデックスを A に集約することができる ## プラハさんでは今までどの CSS-in-JS ライブラリを使用してきましたか？ - この２つをよく使う - styled-components - linaria - emotionの人もいるかも - お気に入りはlinaria - javascriptで書けるけど、最終成果物はcssになる - css-in-jsの欠点 - パフォーマンス (リッチなデザインの場合) - ブラウザでjsを実行して、スタイルを展開する - キャッシュができない - レンダリングコストがかかる - css modulesを使う場合もある - css modulesは使われていないcssがわからない - 無駄なcssに気づきにくい - その無駄なcssで遅くなることもあり得る - css-in-jsとインラインスタイルの違い - https://mxstbr.blog/2016/11/inline-styles-vs-css-in-js/ - css-in-jsで困ったこと - 本来cssでいいのにjsでやっちゃう。hoverとか - set-stateでフラグを持ってやっちゃうと、再レンダリングが起きちゃう - 他にプラハさん内の勉強で調べたリンク集 - https://qiita.com/naomunaomu/items/9b19c8ee71c760ea1ffd - https://yuheiy.hatenablog.com/entry/2018/11/22/020322 - https://postd.cc/stop-using-css-in-javascript-for-web-development-fa/ - https://stackoverflow.com/questions/7261823/how-to-reuse-styles/7261864 ## (特大課題)DDDにおける3階層のリレーションの更新について ### 前提 現在、以下の3つのエンティティがあり、集約をそれぞれ分けています。 - チームentity (参加者へのid参照を持つ) - ペアentity (参加者・チームへのid参照を持つ) - 参加者entity データベースのスキーマとしても、同じく3つのテーブルを作っており、 チーム-ペア間、ペア-参加者間にそれぞれ中間テーブルを作成しています。(3層の階層構造です) ### 質問 このとき、2つある中間テーブルの更新 (=エンティティ同士の関連付けの更新) は、それぞれどの集約の責務とするのがよいでしょうか？ チームentity、ペアentityがどちらも参加者entityへの参照を持っているため、チーム・ペア両方のリポジトリから更新できるようにしたいのですが、処理が重複してしまいます。 現在の実装としては、ペアのリポジトリが両方の中間テーブルの更新を行い、チーム・参加者からは中間テーブルを更新しないようにしています。(しかし、チームentityのプロパティに参加者へのid参照があるのにチームのリポジトリからは何も更新されないのは違和感があります。) ### 回答 - チームのエンティティが参加者へのエンティティの参照を持っているのはなぜ？ - チームに参加者に関するルールがあったため、チームが直接それを知っていた方が良いかと思ったため。ペアがチームの参照を持てばいいかと思うが、ペアのインスタンス参照っぽくなってしまうと思ったから、こうしている。（石原さん） - 松原さんがやった時は、n対nのテーブルがある場合、それも何らかの集約として定義する - ペアという集約の場合、ペアと参加者の間にもn対nがあるので、ペア所属エンティティを自分なら作る - ペア所属エンティティだけだと、困るので。 - チームからペアを外す場合は、チームの方でそれを実施するイメージ - チームの中にペアを含めるかどうかは、ユースケース次第だと思う - 在籍中ステータスがなかったら、全部入れてしまう。ユーザ名を変更することは滅多にないから。 - このステータスがあると、毎回チームとペアを取得するのはどうかと思う - 中間テーブルをエンティティにすることについて - テーブルでは必要だが、モデリングするときはどうすればいいか悩んでいる（中野さん） - 所属自体をモデリングするパターンもあるし、参照のみを持っているパターンも見たことがある - チームの中にIDが入ったときに差分の扱いが難しくなるので、できれば所属というのもレポジトリとして切っておいて、そのインサートとデリートで乗り越えられるようにしたい --- - 中間テーブル自体をentityにする - ペアユーザー所属entity (ペアの集約に入れる) - チームペア所属entity (チームの集約に入れる) - 1つの所属entityが、中間テーブルのレコード1つに対応するイメージ - ドメインルールの整合性を保つため、集約ルートを介して所属・脱退を行う - (今回は難しいが、差分更新のクエリが面倒なので可能な限り所属entityは集約を分けたい) - 集約を大きくするデメリット - 末端のentityの更新が頻繁にある場合、ルートから取得するのはオーバヘッドが大きくなる - チームの人数判定は、チームのドメインサービスにgetUserCountを作ると良さそう - ユーザーのカウントを取ってくるクエリはどこでやる？ - エンティティはリポジトリから生成するのがルール - カウントはエンティティではないので、クエリサービスから取得しても良さそう - 人数が一番少ないチームを探すクエリは、チームのリポジトリにはやしても良いか？ - リポジトリはできるだけシンプルな役割に留めたいが、エンティティに変えていいのはリポジトリだけなので、リポジトリにせざるを得ないのではないか - クエリサービスからはやらないので。 - 書き込みはできるだけシンプルにした方が良いと思う。リポジトリにロジックが漏れ出すから - 読み込みは、複雑になりかねず、そうなっても仕方ないのではないかと思う - 今回チーム数が多くないので、全部とってきてから、ゴニョゴニョする方がDDDらしい - リポジトリをシンプルに保ちたい - テストの数を可能な限り減らしたい - リポジトリはデータベースなどを使用しているため、テストが結合テストになってしまい、テストの実行時間が長くなってしまうため