# a1-group4 議事録 10.Nov.2023
参加者 : 津田、山川、平山、平川、葛原(記)
講師 : 福寄先生（オンライン）
演習時刻 : 18:20-21:45

## 次回までのアクション

## 次回予定

- 日程 : 11/14(火) 18:20~21:30
- 議題 :
・ドメインモデル検討の続き(AWSスライド P.38～の作業)
・今後の変更点検討

## 議題

### 1. 本日の予定
- 葛原キャッチアップ
- 集約の見直し
- 境界付けられたコンテキストの抽出
- 今後の変更点の検討

### 2. 葛原さんキャッチアップ

- 11/2(木)に実施した内容の共有を行った
- step8. 画面遷移について、ログアウトに関する処理が無いのでは？(葛原)
-> 演習の条件として「ログアウト」を取り扱わないことが記されていた。

### 3. Step9 集約の見直し
- 名刺抽出から考えた案と比べると、「操作メニュー」だけ区分として違和感がある。
　- 「readdata」(UI）を検討する際に消えるものだったのでは？
　　　- 上記の通りと考え、一旦削除して考える。

- 「学習コンテンツ(一覧)」「学習コンテンツ（詳細情報）」が分けられている。スッキリできないか？
　- 「学習コンテンツ」としてまとめる。
　 - まとめたほうが良いのか、分割したほうが良いのか判断がつかないことが理由である。
　 - まとめるにしたのは、先の工程に進んだときに振り返るとどちらが良いか切り分けしやすそうだから。'

### 4. Step10 境界付けられたコンテキストの検討
- コンテキスト「ログイン」をまとめた際に、「アカウント」が内包されるが正しい？
　- 別のコンテキストとして表現する？ → 連続性があるから別出しにするのは正しくないと考える。
　　　- 「アカウント」という一つの集約変更し、コンテキストを「アカウント」とした。

- Step9 集約の見直しの結果を受け、トップメニューを削除した。

- 集約した結果を当てはめていくと、違和感が…。Step10'参照のこと。

- 「購入前の学習コンテンツ」と「購入後の学習コンテンツ」は、必要な情報が異なる（視聴時間とか）。別扱いにできるのでは？
　　- サンプルスライドの37ページ目の「商品」が今回の「学習コンテンツ」？

- <講師コメント>境界付けるコンテキストと集約の名称は一致するものではない。
　 - コンテキストは問題を解決する範囲（解決領域）、集約はそのコンテキスト内で扱うもの。

- 購入したコンテンツの表示は「購入済み学習コンテンツの情報管理」コンテキストにまとめるべきでは？そうすれば購入は外部システムを扱うだけで済む。
- 購入時には「購入済み学習コンテンツ」の情報が必要となるけど問題ない？
　　- 全ての「学習コンテンツ管理」コンテキスト内の「選択ポリシー」で購入済みか否かの判断を実施すれば問題なし。

### 5. Step10 境界付けられたコンテキストの検討 ドメインモデルの作成
- Step10 からドメインモデルに落とし込む方法が分からない…。
- <講師コメント>各コンテキストの内容について、スライド37のドメインモデル（概要）を作成すれば良い。
- <講師コメント>その後、データソースを検討→戦術的設計を行いクラス図に仕上げる。
- <講師コメント>名詞抽出した結果と、イベントストーミングの結果を比較・評価できると良いかも。

- 作ってみたけどMVCクラスにならないのが、当初の想定と違う。
- <講師コメント> 観点が違う。ここでは問題完結の領域を考えているので、実装の観点までは入れてはいけない。
- <講師コメント> そのあたりは各コンテキストの中身や、戦術的観点で実装の設計をする場合に考える。

- トップ画面とは？
- 演習説明スライドの13ページ目にある画像イメージ参照。学習コンテンツ一覧、購入／学習履歴を選択する画面。

## メンバー所感メモ

#### 葛原
- 議事書きながら意見出すのは難しい。議論の聞き逃し、記載漏れが無いか不安になる。
- 疑問点や違和感などすぐに言語が出来ないのがもどかしい。ハッキリ意見言えればもっと議論の種になるのに。とりあえず発言して、周りからフォローしてもうか。
- コンテキストと集約については、福寄先生のコメントがあり、理解進んでありがたかった。詳細は上記記載済み。
- 「学習コンテンツ」は購入前、購入後で別データでは無いか？という意見を言ったが、ここでコンテキスト決めで出すのは早かった？ まずは各コンテキストには「学習コンテンツがある（必要な情報量は異なる）」ぐらいにしておくべきだったか？意見出したは良いがあまり成果物作成には直結しなかったかも。
- 画面遷移の話がたびたび出てくるが、画面タイトルレベルでも良いから簡単に作った方がイメージ共有に良いかも。
- ドメインモデルの作成について
- 画面、データ、処理は色分けした方が良いかも。
- 「学習コンテンツの購入」、学習コンテンツの情報を除外することはできないかなぁ。価格だけ渡して課金処理だけ実施するとか…。マイクロサービスのイメージからすると「購入」というサービスだけあって、オンライン学習サービスと切り離せると理想的？これが出来るなら「全ての学習コンテンツ管理コンテキスト」は課金の結果だけ貰って、購入済み判定も行う。そうすれば、購入済み…コンテキストと購入のコンテキストは切り離せる気がする。
#### 津田
- 集約を分けて書いているものをまとめてしまうか議論があった(アカウント、ログイン)。一度まとめてしまって、後工程でどちらのほうがよかったか確認する。
- コンテキストと集約の違いについて福寄先生より指導があり、クリアになった。集約は扱うモノ、コンテキストはモノを処理する「領域」とのこと。平山さんが持ってきてくれた過去の発表資料もあり、理解しやすくなった。
- イベントストーミングで作成した図はかなり、システムの動作やデータを詳細化できているように感じた。特にユーザが行える操作と操作の結果を明示ししているため、マニュアル作成に役立つと感じた。step10まで実施すると仕様との突き合わせもできそう。
- イベントストーミングの結果から、ドメインモデル(クラス図)を作成しようとしたが躓いた。クラスとイベントストーミング図の要素がどう関係するかわかりづらかった。そこで一旦、awsの資料に従って中間的な図である「境界づけられたコンテキストとドメインモデル」を書くことにした。
- どこかの段階で画面遷移図、画面のモックがほしい。メンバーのイメージ共有がそれぞれの記憶だよりなので難しい。
- 進みが遅いことがきになる。成果物に対しての意見が出づらい。質問の仕方、進め方を工夫しないといけないがどうしたら...同じことを初回から繰り返していてまずい。ただ、意見や成果物に対してツッコミがないわけではない(good、嬉しい)ので、考え込ませるような空気感や私の言い方に原因があるかもしれない。
- 他進みが悪い原因として、私が議論を発散させているかも。詳細な話を持ち出しすぎ。突っ込みすぎ。
- もう一日演習日を増やす必要があるかも。
- 次の成果物が明確なら、宿題にして持ち寄る方法を取ったほうが良いかも。ただ、その場合の宿題を確認する時間とみんなで成果物を作る時間にそれほど有効な差がでるかはてな。
- drawioの使用開始に手間取った。事前に予習しておくべきだった...失敗
- 途中で画面がブラックアウトする事象が発生した。共有している画面も表示されなかったみたい。zoomのメニューバーとカメラ画面だけは少し待ったらでてきた。触っているうちにchromeも復帰した。exploer再起動後すると復旧した。
- 他のグループのmiroを覗いてみたところ、ドメインモデル(クラス図)まで書けているよう。
- 時間無いけど一度みんなでほかグループのmiroをさっと見に行くと面白いかもしれない。ほかチームのmiroの使い方がすごく見える。

#### 平川
- 行程のゴール、行程で論ずべき・論ずべきでない領域を明確化して、メンバ内で認識を共有しておく必要がある
- ことイベントストーミングについては、熟練(とまでは言わずとも、経験者)のファシリテーターが必要だと感じた

#### 平山
- 集約とコンテキストがごっちゃになってしまっていた。CodeZineを読み直そう。議論でクリアになってよかった。
- 集約とコンテキストはイコールではない
- コンテキストは解決領域
- 集約は、あつかうもの
- なので、集約では｢通知｣だったのに、コンテキストでは落札通知として登場していた。
- コンテキストは、実装とは関係ない エンジニアであればあるほど実装と関連付けてしまうが、関係ないらしい
- 静的(名詞抽出の手法)と動的(イベントストーミング)で比較できると面白そう、と先生からコメント
- 名詞抽出と比べて、イベントストーミングの方が詳しく出せている気がする。
- そのままマニュアル書けるレベルでは?by津田さん
- 名詞抽出は未完成なので、個人的にやってみる
- drawIOというツールを知った。クラス図も書けるらしい!
-
#### 山川

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

<相談した項目>
(1)集約の見直し
先週作成した集約について、見直しを行い以下を議論した。
・名刺抽出から考えた案と比べると、「操作メニュー」だけ区分として違和感がある。
→「readdata」(UI）を検討する際に消えるものだっただったと考え、削除する。

・「学習コンテンツ(一覧)」「学習コンテンツ（詳細情報）」が分けられているがまとめられないか？
→判断つかないため、今回は「学習コンテンツ」としてまとめる。
→まとめるにしたのは、先の工程に進んだときに振り返るとどちらが良いか切り分けしやすそうだから。

(2)境界付けられたコンテキストの検討
先週作成したイベントストーミングの結果に対して、コンテキスト分けを実施した。
その中で以下を議論した。

・コンテキスト「ログイン」をまとめた際に、「アカウント」が内包されるが正しいか？
→「アカウント」という一つの集約変更し、コンテキストを「アカウント」とした。

・集約とコンテキストは一致するのか？
→<講師コメント>境界付けるコンテキストと集約の名称は一致するものではない。
→<講師コメント>コンテキストは問題を解決する範囲（解決領域）、集約はそのコンテキスト内で扱うもの。

・購入したコンテンツの表示は「購入済み学習コンテンツの情報管理」コンテキストにまとめるべきでは？そうすれば購入は外部システムを扱うだけで済む。
→購入時には「購入済み学習コンテンツ」の情報が必要となるけど問題ないか？
→全ての「学習コンテンツ管理」コンテキスト内の「選択ポリシー」で購入済みか否かの判断を実施すれば問題なし。

(3)境界付けられたコンテキストの検討 ドメインモデルの作成
境界付けた各コンテキストについてドメインモデルを作成した。
その中で以下を議論した。

・ドメインモデルに落とし込む方法が分からない…。とりあえず集約した結果をクラス図にする？
→<講師コメント>各コンテキストの内容について、スライド37のドメインモデル（概要）を作成すれば良い。
→<講師コメント>その中で結局、名詞抽出の作業も必要となるだろう。
→<講師コメント>その後、データソースを検討→戦術的設計を行いクラス図に仕上げる。

・作ってみたけどMVCクラスにならないのが、当初の想定と違う。
→<講師コメント> 観点が違う。ここでは問題完結の領域を考えているので、実装の観点までは入れてはいけない。
→<講師コメント> そのあたりは各コンテキストの中身や、戦術的観点で実装の設計をする場合に考える。

・トップ画面とは？
→演習説明スライドの13ページ目にある画像イメージ参照。学習コンテンツ一覧、購入／学習履歴を選択する画面。

<指示された事項>
演習の実施中に判断した事項は、判断した理由を記録しておくこと。
振り返った際に、結果とあわせて理由についても考慮しなければ、同じ失敗を繰り返す可能性がある
<次回のミーティングまでに取り組む項目>
特になし。
<次回の打合せ予定>
日程 : 11/14(火) 18:20~21:30
議題 : ドメインモデル検討の続き(AWSスライド P.38～の作業)
　 今後の変更点検討