こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
アイスブレイク
職場の話や仮説検証をする際に意識していることの話、仕事を改善していくためのモチベーションなどをアイスブレイクとして話していきました。
良い意味で、アイスブレイクという言葉とはだいぶGapがある深い話でした。
本書で気になる箇所
この読書会はまずはがんがん読み進めていくことを目標にしているので、読み切った後に議論したい内容や気になる箇所を話し合っていきました。以下、議論したい内容や気になる箇所として挙がっていた内容を箇条書きで記載していきます。
- モノリシックアプリケーションの分割が可能かを測る指標として、コードベースで共有されているコンポーネント数などが妥当であると考えられている理由はなにか？
- コンポーネント分離を選択した判断は書いてあるが、サブドメイン案を選んだ時のメリットが書いてない。サブドメイン案が妥当な判断となるようなコンテキストはどのようなときだろう？
- ドメインサービスとはコンポーネントのまとまりを指しているのか？
- サッカーボールの点線は何を指し示しているのか？どうしてデータドメインを横断していると別のスキーマに抽出する際に削除する必要があるのか？
- データベースコネクションをデータドメインごとに分離すると、データベースの参照整合性が保たれないのはなぜか？
- データドメインとスキーマの関係は通常1:1だが、データドメインは複数スキーマにもマッピングすることができる、というのがよく理解できなかった
- デメリット2つめの、なぜデータベースの参照整合性が保たれないかが書かれていないためわからない
- 幅広い種類のデータベースを触ったことがないこともあり、データベース種別の解釈の仕方、読み解き方が難しい(NewSQL?、時系列DB?)
- 集約志向を深堀して考えたい
- コンポーネントベース分解パターンが解説されている本が出版されているはずなのだが、これはもう出ているのか？
- 基準を決めてその基準を満たす様に分割していく方針は分かりやすい反面、前章までで記述されていたような過剰なコンポーネント分解に繋がるリスクもありそうに感じたがどうなんだろう？
- ドメインを切り出す時に「〜管理」は使わない様にしているんだけど、例では普通に使われている…皆さんが気にしているのかそんなに気にしていないのかを是非聞いてみたい
全体を通した感想
今日は議論というよりも今後話したいことを整理していくような会でしたが、その中でも色々お互いが想うことのかけらが話し合えたのでよかったです。
今日出ていた議論ポイントの内容も意識しながら、後半を読み進めていきたいと思います。
