# a1-group4 議事録 28.Nov.2023
参加者 : 津田、山川、葛原、平川、平山
講師 : なし
演習時刻 : 18:20-21:40

## 次回までのアクション
- 各サービスのクラス設計は出来たら、miro上に貼っておく。（努力目標。12/8(金)までには必ず記載しておくこと）
- どのように説明するかは、次回開始30分で相談する。

## 議題
- シーケンス図作ってくる → 途中経過をmiroに随時置いておく
- 変更点をちょっと考えておく

### 1. 各位が作ったシーケンス図・クラス図のチェック
- 学習アドバイザシステム
- chat GPTへのチューニング方法どうする？
- 一覧を渡して学習してもらう方法で実施している。
（実態はコストかかったりするので、分かりやすさ重視）
- ドメインとインフラは1:1?

- 全ての学習コンテンツ管理コンテキスト
- 購入済み学習コンテンツ一覧をどう表現する？他のコンテキストからのデータはどこから取ってくる?
- app層から取ってるのではないか？
- 購入済みデータは複数のコンテキストでデータ必要、取得するとオーバヘッドや負荷が気になる。★ みんなで相談したい！
- インフラストラクチャ層の中身は複数合ってよい？
- 資料見てると1つのみっぽい？ 複数あるのは集約が大きくなっている？（集約ごとに1つのDBとなるのでは？）
- まとめられるのであれば1つにするのが良さそう。→1つにまとめましょう。
-
- 購入済み学習コンテキスト
- 購入コンテンツ一覧、購入履歴は情報としては同じもの
- 購入履歴は無くして、「購入済み学習コンテンツ」を作成。購入日時を追加。
- 学習履歴は章にくっつくものでは？
- バージョン1 「購入済みが学習コンテンツ」を介してDBアクセスするのは違和感。欲しいのは一覧だけど、一個ずつとるの？
- 詳細設計の観点が入ってるかも。ただ、バージョン2がすっきりして良さそう。
- 購入済みコンテンツ一覧を表示→コンテンツを選択する→詳細を表示するの流れに直した方が良い。
- イベントストーミング step10の話。

- 購入コンテキスト
- 購入しているか否かは「学習コンテンツ管理」のポリシーで判断する。
- ユースケース記述とは若干差異あるが、チーム内でユーザ定めて判断した結果現状の結果がユーザに望ましいと結論づけた。
- 購入履歴は購入コンテキストが保持する形とする。
- pubsubパターンで、他のコンテキストにデータを撒ける様にする。

- 視聴コンテキスト
- UIとAPP層の関係は？1:1?

### 2. 上記の結果を元にクラス図を編集
- pub/subパターンを適応したいがどのように書けば良い？ brokerはどこ？
- データを送りたいコンテキストが、brokerを持っていれば良いのでは？
- それだと各コンテキストでbrokerを持つことになる、システムで1つ持つのでは？
調べるとbroker役のイベントが別途いたりする。
- AWSでもpub/sub用のサービスがあるため、brokerは別コンテキストして出す。

- pulisherはapp層から経由で出るべきでは？
- データのやり取りと考えてインフラ層で実施すると考えられるのでは？
- 実際に図示するとそちらがスッキリする。
- データ通信が必要なのはなぜ？
- 直で他のコンテキストに出るのは違和感のため
- 色々意見でたが、先ずは分かりやすい方向で記載するため、publisherから直接brokerへの記載とする。
他に良い方法あれば、先生に聞きましょう。

### 3.

### 4. 次回
次は追加で12/01(金)

## メンバー所感メモ

#### 葛原
#### 津田
#### 平川
#### 平山
#### 山川

# 議事録テンプレに直したもの

<相談した項目>
### 1. 各位が作ったシーケンス図・クラス図のチェック
以下5コンテキストについて、各自が作ったシーケンス図・クラス図を確認し、ディスカッションを行った。
- 学習アドバイザシステム
- 全ての学習コンテンツ管理コンテキスト
- 購入済み学習コンテキスト
- 購入コンテキスト
- 視聴コンテキスト

ディスカッションのポイントとなったのは以下の点である。
- 「購入履歴」は管理責務はどのコンテキストが持つか？
- 購入履歴は購入が完了したタイミングで更新されるべき情報と考えるため、購入コンテキストで管理する。
- 他コンテキストが購入履歴のデータを使用する必要があるため、pub/subパターンを適応して他コンテキストに通知出来るようにする。

### 2. ディスカッションした結果を踏まえてシーケンス図・クラス図を変更
ディスカッションした結果を踏まえてシーケンス図・クラス図を変更した。

この際にディスカッションしたポイントは以下の点である。
- pub/subパターンを適応する場合に、publisher/brokser/subscriberはどこが持つ？
- publisherはデータを通知するコンテキストが持つ。(データを保有するコンテキスト 購入コンテキスト／視聴コンテキスト)
- subscliberはデータを受信するコンテキストが持つ。
- brokerはデータを通知するコンテキストが持つ？
- 色々調べるとシステムとして1つのbrokerを持つのが正しそう。
- AWSなどでは1つのサービスとして存在している。→ 各コンテキストが持つのではなく、1つのサービスとして作成する。

<指示された事項>
なし
<次回のミーティングまでに取り組む項目>
- 各サービスのクラス設計は出来たら、miro上に貼っておく。（努力目標。12/8(金)までには必ず記載しておくこと）

<次回の打合せ予定>
日程 : 12/1(金) 18:20~21:30
議題 : 中間報告