# a1-group4 議事録 1.Dec.2023
参加者 : 津田、山川、平川、平山[記]
講師 : 福島先生(ときどき)、安田先生(ときどき)
演習時刻 : 18:20-21:30

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

## 発表用メモ
- ドメイン分析の手法としてイベントストーミングを選択
新しい手法を試してみる
名詞抽出(静的な方法)との比較ができたらしたい
- step1ドメインイベントの洗い出し、step7アクターとポリシーの洗い出しとstep9集約がイベントストーミングの肝だと感じた。
イベントをもれなく洗い出すこと、イベント間の連続性(つながり)を見つけること、機能を作ることにつながる
- 演習を通じて集約とコンテキストが違うと理解できた

## 発表用メモ 静的解析との比較(平山)
- ICONIXは、名詞抽出して振る舞いの無い(クラス図のメソッドなし)静的なモデル作って、その後、ユースケースごとにロバストネス分析で振る舞いを作っていく。
- 今回はイベントストーミングで進めている。ふるまいに着目して進めているので、ICONIXの流れで進めるのは難しい
- 授業でのドメイン分析は、画面がどうとかボタンがどうとか、実装的な内容は出ていなかった。一方、学習サービスは、かなり詳しくユースケース記述が存在している。前者は概念しかなかったので名詞抽出と分類がしやすかったが、後者が逆に詳しく情報がありすぎて、そのまま名詞抽出すると、UI系など概念レベル以上のものが出てきてしまう。

- 機能は省く
- 名詞抽出すると、機能がいっぱいでてきた
- 機能は省くと書いてあった
- かなりの部分が省かれた → 静的なのでメソッドは省くということ
- - ドメイン分析の段階では、UIや操作に関する項目は分離して検討した方が良いかもしれない
- イベントストーミングの方法がよくわからず試行錯誤していたところ。UIはリードモデル
- UIは
- イベントによってどう状態が遷移するのかなど、すでにある状態
- イベントストーミング終わって、ここからどう設計に進むかわからず、ICONIXの途中から合流しようとしたが、すでに
- 両者の違いをふまえて、比較結果をまとめていきたい

## 議題
### 1. 他の発表内容を聞いて思ったこと（改善点等）
- 画面遷移よかった
- サービス分割しすぎているとオーバーヘッド増える
- マイクロサービスアーキテクチャとは何か、なんでわけるかを発表では話す
- シーケンス図書いている班がなかった
- サービスの名前の付け方は良かった!by福島先生、福寄先生
- かっこつけてざっくりつけると、わかりづらくなる
- かっこわるくなるかもしれないけど、役割を定義してそれが伝わる名前にするのが大事
- 福島先生より、てい先生のコメント補足(てい先生のコメントは、平山のメモ部分に書いておいた)
- 今回の課題は、ユースケースがある
- てい先生のは、要求分析と業務分析がわかれていた
- 今回は要求分析はすでにやられている
- どういうシステムを作るのかではなく、業務領域をモデルかするのが業務分析。要求分析がすでにあると、作られそうな分析になっていっちゃう。ログインは、どっかに入室するという実際があり、それをどう変換しているか。今回の課題設定が勘違いを生みやすい状況というのもある。本当はこうした方がよかったとか考えてみる。
- クライアントがシステム化を要求するのが要求分析。業務分析はシステムの言葉はない(ログインとか) 学習する とかを分析する。今回は要求分析がすでに終わった状態になっている。

### 2. 変更点の確認
- 過去の学習履歴の要約
- 学習履歴のデータは何%学習されている情報がある
- A講義→B講義 今受けている講義を受けて、次のどれを受けたほうがいいかを提案。これまで設計の授業受けてきたので、〇〇設計の授業はどうですか?
- ChatGPTに投げて、どのコースかわかるの?
- ここは忘れてもらってもいい。時間あれば考えてもよい。
- 購入/学習履歴画面とは?
- 購入一覧→詳細画面の遷移じゃないの?
- エクステンションする?
- 決め事

### 3. 今後やること
- 優先度は低いですが、なぜこうしたかの根拠は全員で確認が必要かなと思いました
- 色々散らばっているので、miroのフレームにまとめる?
- どの先生も、どう設計したかよりも、どういうところに苦労したか、どういう理由でそうなったが大事と言ってる
- ドメインモデルを中心に設計すると業務の変更に柔軟に対応できる、逆に制約ベースで考えると業務の変更に対応できない（やりたいことが実現できない）というのは大事だなと思いました（仕事でよく直面する課題なので）

### 次回
- スケジュール確認
- 日程追加も含めて話す
- 詳細設計の宿題
- Pub/Subの適用
- 値(メンバ変数)も可能な限り入れる
- 仕様変更入る前のものを作ってくる(あとで変更容易性の考察をするため)
- ドメインモデル図
- イベントストーミングから手を加える?
- アーキテクチャ
- なぜこうしたかの議論事例のまとめ先を検討

## メンバー所感メモ

#### 葛原
#### 津田
#### 平川
#### 平山
- グループ1
- 販売促進というのは面白い!
- グループ2
- UIコンテキスト持たせるってところ、うちと似てる!
- セッション管理はどうする? 同じ疑問あったな
- マイクロフロントエンド
- グループ3
- ICONIXからイベントストーミングに
- メンバ間のそご→ユビキタス言語
- 概念クラスはどう分けたらいいか。どっつきやすいか
- グループ4
- サービス増えすぎて通信が増えていくのでは?
- 責務はどうするかで議論でてきた
- コンテキスト名は、グループ1はざっくりなので認識合わせが難しいのではと思っていたが、うちは具体的に置いているので、よい とコメント
- てい先生
- 今回は、ドメインの分析をした結果から設計をしようとしている。ただ、いま指しているのがドメインなのか詳細設計モデルなのかはよく分けて考えてほしい。ドメイン→設計をしていて形が似ているので、一緒にまざっているかもしれない。ドメインモデルを作るときに、設計のことを考えないことが大事。ドメインに合わせておけば、ドメイン(業務)の変更に強い。ドメインモデルを中心に設計する。こうする方がはやそう、こうする方が管理しやすそうとか考えるのはまずい。ユースケース記述にシステムに近いことが書いてあることもあり、そうなってしまっている要因もある。ログイン→承認 画面遷移は静的分析では失われてしまったという話があったが(多分平山のこと) 失われてしまった、ではなくドメイン分析には不要だったのでは という議論は必要 画面遷移とかはドメインに不要
- ドメインを中心に考える
- なんでそういう結果になったのか、理由は?
- イベントストーミングみんなやっているのに違うから。
- 議事録は議事録で、こう考えてこうした みたいなことはmiroにまとめたい。でもどこに置いたか見失いがち。各フレームではなく、どこか専用のフレームにまとめた方がいいかも
- 忘年会は行けない(とちぎ住み)
- 仕様変更
- 全然予想していなかった!
- 変更容易性を持っているか、持っていなかったか、考察するために仕様変更を行っている。そこを話してほしい
- 今後
- 他でも仕様はよりよくなるように変更してもOK
- 年明けからはまとめに入る。考察中心
- レポートの書き方、どうまとめるか 形式は
- 各自の貢献ポイントを書く
- 発表
- 同じ課題を4グループやってるので、課題は各グループから代表者出して説明してから、各グループの発表

#### 山川

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

<相談した項目>
### 0.
### 1.
### 1.
### 2.
### 3.
<指示された事項>
なし
<次回のミーティングまでに取り組む項目>

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