# 添削者サービス　第11回

| 日付 | 6/5 |
| -------- | ---------------------------------- |
| 主催 | 松田 |
| 開始時刻 | 21:00~ |
| 終了時刻 | |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 池側、松田耀、福田、阿部|

## 現在の進捗
- 教務研究員コンテキスト
- 阿部さんの方で完了、developにmerge済み
- チームコンテキスト
- routerの動作検証
- team：松田さん
- member: 池側

# 添削者サービス 第10回オンラインコーディング
| 日付 | 6/5 |
| -------- | ---------------------------------- |
| 主催 | 池側さん |
| 開始時刻 | 15:00~ |
| 終了時刻 | |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 池側、神保、松田耀、山田、大鐘|

## 進捗と残りタスクの確認

- 教務研究員コンテキスト
- 進捗は第9回議事録を参照
- 残りタスクは残り4つのエンドポイントを実装
- controllerは実装済み
- レスポンスがこれでいいか怪しい
- 例: 教務研究員追加ではレスポンスでサービスで振ったidを返す方がいい？
- services/employee/__init__.py, infrastructure/servers/route.pyで主に実装を行う。
- matsuda/feature/employee/controllerをpullして、docker-compose upで立ち上がる

- チームコンテキスト
- 残りタスク
- domain層の実装が若干おかしそうなのでそこの修正もmtg中にしたいです。(松田(耀))
- usecase実装
- controller実装
- 実際にAPIとDBを繋げて検証を行うためのdocker環境の構築（複雑かも... 下のブランチのdocker-compose.yamlを一つ一つ見ていくと理解できると思います。）
- dockerやDBの設定は教務研究員コンテキストを早めに終わらせてマージした上でそちらのを利用する形で良いと思います。コンテキストに依らず共通になるので(阿部)
- router周りの実装
- 各種実装, docker環境に関しては教務研究員コンテキストのmatsuda/feature/employee/controllerを参照してください

### チーム分け
- 教務研究員コンテキスト
- 山田, 大鐘,（阿部）
- チームコンテキスト
- 池側, 松田（耀）, 神保 , (中井)
-
## 進捗
- 教務研究員コンテキスト
- route.pyの実装まで一通り完了
- エラーハンドリングの実装と検証がもう少し必要
- チームコンテキスト
- ドメイン層の修正
- Teamモデルがmembersを持たない問題
- db_gatewaysでのエラーハンドリング
- Controllerの実装
- 完了
- teamのcontrollerは[PR#91](https://github.com/nagaseitteam/it-service/pull/91)
- updateはpending
- controllerのメソッドとして持たせるのはCRUDのみ？？細かいユースケースはどのように使うのか
- routerの実装
- 未完成→次回までのタスク
- teamに関して：松田耀さん
- memberに関して：池側

# 添削者サービス　第9回オンラインコーディング
| 日付 | 6/3 |
| -------- | ---------------------------------- |
| 主催 | 松田（和） |
| 開始時刻 | 20:00 |
| 終了時刻 | |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 中井, 阿部, 松田（耀）, 池側, 山田, 神保, 北浦, 大鐘, 福田|

## 現状の進捗

- 教務研究員コンテキスト
- ユースケースの実装完了
- 動作検証も簡単なものはある程度完了
- feature/emaminer/domain-modelingにマージしたい
- チームコンテキスト

## 残りのタスク

- 教務研究員コンテキスト
- APIとして提供するエンドポイントを決める
- リクエスト, レスポンスを定義
- controllerとrouterを追加
- チームコンテキスト
- domain層を実装しきる
- まずリポジトリ実装
- ユースケースを実装
- TeamRepositoryだけ書けてれば並行して進められる
- その後は教務研究員コンテキストと同様

[リポジトリの実装例](https://github.com/nagaseitteam/it-service/tree/nakai/work_segment/infra/api/services/work_segment)

## 実装

メンバーの方はこちらに、決まったことや進捗などを記入していってください。

松田（和）, 阿部, 山田
- 教務研究員コンテキスト
- dockerの環境構築（阿部さん）
- usecaseを実装（松田, 山田）
- 教務研究員追加のエンドポイントの実装、検証が完了

池側, 中井, 福田, 松田(耀), 北浦, 神保
- チームコンテキスト
- 進捗
- team_repository.py: 松田さん
- team_repositoryの修正で[PR#80](https://github.com/nagaseitteam/it-service/pull/80)立てました。
- adapters/db_gateways/member.py: 神保さん
- ~~手元の環境が壊れていて未完了~~
- team3/feature/... へpushしました
- domain/interface/db_gateway.py: 福田さん
- [PR#81](https://github.com/nagaseitteam/it-service/pull/81)
- adapters/db_gateways/team.py: 池側
- 日曜日までの予定
- UseCase実装
- 池側：init+メンバ0追加＋メンバ削除
- 神保：続き＋usecase職階変更～まとめて取得の3つ
- 松田：applications/team_usecase.←やる

# 添削者サービス　第9回オンラインコーディング
| 日付 | 5/26 |
| -------- | ---------------------------------- |
| 主催 | 松田（和） |
| 開始時刻 | 21:00 |
| 終了時刻 | |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 池側, 山田, 石津, 土井, 福田|

## PRに関して
教務研究員コンテキスト
チームコンテキスト

## 進めていきたいこと
- 教務研究員コンテキスト
- usecaseの実装
- usecase一つ一つはimportして提供する単位
- テストの際はテスト用のdb_gatewayを使用する
- APIとして提供するものはcontrollerとrouterを用意
- チームコンテキスト
- テーブル設計とrepository周りの実装
- あとは教務研究員コンテキストと同様

## flake8の警告が出るようにする
ダウンロードできたら書いてください
- 池側
- 石津
- 山田
- 福田
- 土井

あとでやり方のアナウンスをします

## 教務研究員コンテキストのユースケース
- 教務研究員を追加する （山田）
- 教務研究員を削除する　（土井）
- 教務研究員の職階を変更する（リーダー人事chのtextから）　（松田）
- 教務研究員の情報を取得する(by教務研究員ID)　（山田）
- 職階がリーダーの教務研究員の一覧を取得する　（土井）
- 教務研究員を検索する　（松田）

[実装例](https://github.com/nagaseitteam/it-service/tree/nakai/work_segment/infra)

## 作業
- 教務研究員コンテキスト
- ブランチはfeature/employee/domain-modelingから切る
- チームコンテキスト
- テーブル設計、repository実装
- repositoryの実装に関しては[こちら](https://github.com/nagaseitteam/it-service/tree/nakai/work_segment/infra)を参照

## 次回までのTODO
- 教務研究員コンテキスト
- ユースケースの実装
- matsuda/feature/employee/usecaseで作業
- テストを書く
- ディレクトリを用意する
- チームコンテキスト
- db_gatewayの実装
- repositoryの実装
- テーブル設計を中井さんに確認していだたく（松田）

            erDiagram
                Member {
                    int p_id
                    int pf_team_id
                    datetime assigned_at
                    string rank_type
                    datetime rank_type_updated_at
                }

                Team {
                    int p_team_id
                    string team_name
                    string subject_name
                }

                Member }o--|| Team : ""

- Team毎にMemberを作る感じで考えたのですが、Memberの属性からteam_idを外して、team_idとmember_idのマッピングテーブルを作るべきでしょうか？？

# 添削者サービス　第8回オンラインコーディング
| 日付 | 5/26 |
| -------- | ---------------------------------- |
| 主催 | 松田（和） |
| 開始時刻 | 19:00 |
| 終了時刻 | 21:30 |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | |

## 進捗
- 教務研究員コンテキスト
- ドメイン層の実装が完了（エンティティやリポジトリ、インターフェースなど）
- adaptersでdb_gatewaysを実装
- チームコンテキスト
- main.pyに実装したドメイン層を切り分ける
- usecaseの切り分け
- チームの追加を行うエンドポイントの実装を行いました（未検証）
- 説明付き

## 進め方

コンテキストごとに分かれて進めていきたい

基本的な流れ
- ユースケースを洗い出す
- 例： チームを追加する など
- チームコンテキストはある程度洗い出している
- 洗い出したユースケースをapplicationsで実装
- ドメインモデル図で実装できるか確認
- なければドメインモデル図を変更の後、ドメインモデルから実装
- このとき、domainsにあるものを使って行う
- dbに関連する場所はdb_gateway_interfaceを使う
- チームコンテキストではDBの設計から行う
- db_gateway_interfaceはテーブル単位で用意する
- ユースケースをテストする？
- test_servicesディレクトリ内
- dbに関する部分はdb_gateway_interfaceを継承して作ったテスト用のデータを用意する？
- この時点で、他サービスでimportして使われる単位での機能は完成
- 上のユースケースの中でAPIとして提供したいものを決定
- それに対して、adaptersでcontrollerとinfrastructureでrouterを用意する

疑問
- 他のサービスは、実際のdbで動作検証してる？

- 教務研究員コンテキスト
- applicationsでusecaseを定義
- このコンテキストで行いたい処理を洗い出す
- それに対して1対１でメソッドを用意
- adaptersを実装
- controllersではusecaseを使う
- controllersの役割
- リクエストとレスポンスの変更がしやすい？
- infrastructures
- servers/routerでルーティングを実装
- ここでadaptersを呼び出す
- このことでframework変更の影響をrouterで閉じ込められる
- controllersでfastapiのbasemodelを使っているのが気になるが....

- チームコンテキスト
- repositoryをdbを使用するように変更
- db_gatewayの実装
- テーブル単位で実装
- テーブル設計が必要
- applicationsでusecaseを定義
- コンテキストで行いたい処理は大体洗い出している
- それに対して1対１でメソッドを用意
- 以下は教務研究員コンテキストと同様
- teamコンテキストの例を参照しながら

人数が少ないので、テーブル設計を行わない教務研究員コンテキストで作業

# 添削者サービス 第8回オンラインコーディング
| 日付 | 5/20 |
| -------- | ---------------------------------- |
| 主催 | 松田（和） |
| 開始時刻 | 20:00 |
| 終了時刻 | |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 中井、池側、畑中（21：00−）、神保、石津、西川、土井、阿部、北浦、大鐘 |

## 前回のTODO
- チームコンテキスト
- 人事importサービスは池側さん
- 中井さんからのフィードバック分に関して修正していただいた
- repository以外は松田（和）
- repository以外の修正を行った
- メンバー登録日仕様の命名に関して、PEP8に違反してしまったので元に戻しました '\'使ったのですが、それはそれでエラーが出ます
- 数カ所気になったことがある
- repositoryは今回のmtg
- - 現状のwork_segmentのrepository<->db_gateway_interface<->db_gatewayのあたりを読んでおくと良い
- 教務研究員コンテキスト
- 阿部さんが修正の後、中井さんに確認していただく
- repositoryに問題あり
- 一般教務研究員と教務研究員リーダーで持つ属性が違う
- テーブルの分割するかどうか

## 今回のタスク
実装に関しては、[こちら](https://github.com/nagaseitteam/it-service/tree/nakai/work_segment/infra/api/services/work_segment)を参照してください

ユースケースまわり (チームと教務研究員は別)
- ユースケース洗い出し
- 参考箇所 第4回オンラインコーディング 洗い出したユースケース一覧　or 添削者サービス内オンラインコーディング 第2回の内容 or その他思いついたもの
- application層に1:1で書く
- applicationsディレクトリ内
- クラスの切り分けに関しては、データベースのテーブル単位が目安？
- controller
- route
- DB周り (チームと教務研究員一緒に)
- 現状のwork_segmentのrepository<->db_gateway_interface<->db_gatewayのあたりを読んでおくと良い
- リポジトリ周り
- db_gateway_interfaceの作成
- リポジトリをdb_gateway_interfaceを使った書き方に修正
- db_gateway周り
- db_gateway_interfaceを実現するdb_gatewayの実装

今回、main.pyに書いたものはdomainsディレクトリの中に分けて書いていくのか？

## チーム分け
- 教務研究員コンテキストのユースケース
- チームコンテキストのユースケース
- DB周り

## チームコンテキストすること
- nakai/team/refactorのPEP8違反を直す
- team3/feature/examiner/domain-modeling <- nakai/team/refactorのPRをマージ
- team3/feature/examiner/domain-modelingでmain.pyを各ファイルに切り分ける
- usecaseの中身を実装する

→切り分けまで完了しました。usecaseの実装にはまだ手が付けられていません。

## データベース設計

* 教務研究員
* リーダーと一般教務研究員をどう分けるか
* リーダーは職階タイプと職階変更日を持つが、一般教務研究員は持たない
* テーブルは同じ
* dbゲートウェイは分ける
* 運用面で「リーダー特有の機能の追加」などをしないことが前提であれば同じでよい。
* README.mdやドキュメントで各必要がある
* 職階は一つの属性になって、リーダーとメンバーはエンティティとして別れない
* チーム
* ID
* 名前
* 科目(Optinal) string
* メンバー
* 教務研究員ID（FK）
* チームID（FK）
* 複数のチームに所属していた場合はレコードが増える
* 名前
* 採用日
* メンバー職階タイプ
* メンバー職階更新日

メンバーはナガセIDとチームIDの二つでユニーク

教務研究員とリーダーエンティティを分ける必要性は？

## TODO

# 添削者サービス 第7回オンラインコーディング
| 日付 | 5/18 |
| -------- | ---------------------------------- |
| 主催 | 松田（和） |
| 開始時刻 | 21:00 |
| 終了時刻 | |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 中井、池側、畑中、神保、石津、西川、土井、阿部 |

## 現在の進捗について
- 教務研究員コンテキスト
- クラス定義は全て終了
- 修正は必要
- アプリケーション層のユースケースを考える必要がある
- このmtg中に中井さんからフィードバックをいただく
- ユースケースは網羅できましたでしょうか？（to 阿部さん）
- 教務研究員追加などはサービスを使うのでは？ 現状、repositoryを使っているように見えた
- チームコンテキスト
- 人事制約など細かい制約が実装できていない
- 中井さんの方から[フィードバック](https://github.com/nagaseitteam/it-service/pull/30#pullrequestreview-975761401)をいただいています
- これ以外にあったらお願いします。（to 中井さん）

## 今日やりたいこと
- ドメイン層の修正
- インフラ層などの把握（簡単にご説明いただけるとありがたいです。）
- [実装例](https://github.com/nagaseitteam/it-service/tree/nakai/work_segment/infra/api/services/work_segment)
- adapters
- controllers
- db-gateways
- repositoryとgatewayの違い
- gatewayは単純なdb操作を行うイメージですか？
- applications
- usecaseがある
- ここにドメイン層の```if __name__='__main__'```を書いていく感じか？
- domains
- ドメインモデル図などで定義したことを実装
- infrastructures
- db-drivers
- servers
- routerを定義

- インフラ層はドメイン層に依存する？ その場合は、ドメイン層が完成しないとインフラ層などに入れない感じですか？
- こちらは設計なしで大丈夫ですか？ このままだとかなり個人で実装が分かれそうですが....
- 何をするかわかるレベルまで持っていきたい

## 残っていること
- 教務研究員コンテキスト
- アプリケーション層のレベルでのユースケースの洗い出し
- ドメイン層のリファクタリング
- 中井さんのフィードバックからの修正
- チームコンテキスト
- 人事制約などの細かい制約の追加
- 人事決定のためか検証のためかによる
- 検証のためならあってもいい
- 中井さんに確認

## 実装

- 教務研究員コンテキスト
- 教務研究員はTeamのIDを知らないが、Teamのほうは教務研究員のIDを知っていることが求められるのか？
- nakaiさんのPRのレビューをもとにidは不定とするように修正
-

## 分担
- 教務研究員コンテキストグループ
- 残っているタスク
- インフラ層グループ
- インフラ層などの実装例を確認していだだき、質問などを議事録に書いていただく
- ドメイン駆動設計に関する質問などあれば、それでもいい

## 確認したいこと
- 教務研究員コンテキストのフィードバック
- チームコンテキストへのフィードバック（あれば）
- チーム人事ファイルimportサービスで参照する人事制約は必要かどうか？

## TODO
- チームコンテキスト
- 人事importサービスは池側さん
- repository以外は松田（和）
- repositoryは次回のmtg
- 教務研究員コンテキスト
- 阿部さんが修正の後、中井さんに確認していただく

## 次回

- ユースケースまわり (チームと教務研究員は別)
- ユースケース洗い出し
- application層に1:1で書く
- controller
- route
- DB周り (チームと教務研究員一緒に)
- 現状のwork_segmentのrepository<->db_gateway_interface<->db_gatewayのあたりを読んでおくと良い
- リポジトリ周り
- db_gateway_interfaceの作成
- リポジトリをdb_gateway_interfaceを使った書き方に修正
- db_gateway周り
- db_gateway_interfaceを実現するdb_gatewayの実装

## 来週のmtg
- 5/20（金） 20:00~

# 添削者サービス 第6回オンラインコーディング

| 日付 | 5/14 |
| -------- | ---------------------------------- |
| 進行 | 北浦 |
| 開始時刻 | 19:00 |
| 終了時刻 | |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 北浦、阿部，松田(耀)、神保 |

本日は松田（和）が参加できないので、北浦さんに進行を務めていただきます。
議事録の方だけ残させていただきます。
mtg中に決まったことは、どなたか議事録の記入をお願いします。

今週から添削者サービスに土井さん、石津さんに入っていただきます。
これからよろしくお願いします。

## これからのスケジュール（再掲）
- 今週(5/15まで)
- ドメイン層のコーディング
- ユースケースのサンプル作成まで
- 来週（5/20まで）
- インフラを含めた残りのレイヤーの実装
- 再来週(5/27まで)
- デプロイまで

## 今週のタスクについて

### 今日までに終わらせるべきこと
- ドメイン層の実装
- ユースケースのサンプルが動くようにする

### 現状終わっていること（松田（和）の把握している部分）
- 教務研究員コンテキスト
- 以前のmtgから阿部さんの方で人事読み取りサービス以外のドメイン層は一通り実装していただいた。
- チームコンテキスト
- 以前のmtgでドメイン層の実装は完了している

### 今週の残りのタスク
- 教務研究員コンテキスト
- 人事読み取りサービスの実装
- ユースケースのサンプルが動くようにする
- チームコンテキスト
- 動作確認が終了していないユースケースのサンプルが動くようにする
という認識です。

## 実装
グループに分かれて実装に入ってください
参加人数にもよりますが、教務研究員コンテキストとチームコンテキストで分かれるのがいいかなと思います。

* (C)メンバー職階の変更：Team2
* チーム人事ファイルimportサービスでファイルを読み取りメンバーリポジトリに渡す
* 豊本さんが持っているexcelのファイルを読み込むためのサービス
* この際、人事制約を参照し、例えばリポジトリにアクセスして「いつ現在の職階になったか」などの制約条件を確認した上でメンバー職階を変更するなどのユースケースに応えられる
* 他にも、AIチームのように稼働時間に制約がある場合も、日報サービスにアクセスして...という処理を実装可能
* 教務研究員コンテキストのimportサービスは添削者IDと職階が必要で、添削者がどのチームに属しているかは必要ではない。
* ここでの職階
* リーダーか添削者か否か
* リーダー側
* サブマネージャー
* マネージャー
* リーダー
* シニアリーダー
* それに対し、チームの方のimportサービスは添削者id+職階+チームの情報を更新するサービス
* ITと物理でそれぞれの職階を持つべきでそれぞれに対して変更
* ITと科目のMAXの職階をその人の職階とする話とは切り離す
* 例
* IT：リーダー
* 物理：マネージャー

土井さん、石津さんには
- グループ内の詳しい方に「これまでの設計と実装の流れ」に関して説明していただき、実装に加わっていただく
- それが難しそうであれば、土井さん、石津さんの別グループでDDD＋添削者サービスの設計を学習、理解していただき質問対応などで理解を深める
このいずれかをしていただくのがよいと思います。

### 進捗

- 添削者コンテキスト
- 人事サービスのCSVのparseについては責務を別とした
- それ以外は実装完了
- それ以外については実装、検証が完了
- チームコンテキスト
- https://github.com/nagaseitteam/it-service/tree/team3/feature/examiner/domain-modeling
- push済みなので確認していただけると…（畑中）
- ○あるチームに所属しているメンバー一覧の取得
- ▲メンバー職階変更サービス

## 来週のうちに実装すべきことの確認
- ドメイン層以外の実装を5/20までに終わらせるということですが、具体的にどういった部分を実装していくのか確認しておくことが必要だと思います。
- 中井さんがいるタイミングで改めて確認

## 次回のmtg
日程調整の後でアナウンスします。

# 添削者サービス 第5回オンラインコーディング

| 日付 | 5/10 |
| -------- | ---------------------------------- |
| 主催 | 松田(和) |
| 開始時刻 | 21:00 |
| 終了時刻 | 24:30 |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 池側，松田(耀)、畑中、北浦(22:20〜) |

## 前回のオンラインコーディングからの進捗がある方は記入をお願いします。
-

## これからのスケジュール
- 今週(5/15まで)
- ドメイン層のコーディング（テスト込み）
- 注意：メソッドレベルのテストではない
- 来週（5/20まで）
- インフラを含めた残りのレイヤーの実装
- 再来週(5/27まで)
- デプロイまで

## 今週のタスク

- ドメイン層の実装
- ユースケースのサンプル作成

## 今日のタスク

- ユースケースのサンプル作成（必要なドメインモデルが未実装ならドメイン層も追加で実装）

- ユースケースの一連の流れが把握できないとき
- [こちら](https://n-contents.backlog.com/alias/wiki/667701)のようにシーケンス図を書いてから始めるとやりやすいかと思います。

### 本日の進捗
教務研究員コンテキスト
- サービスやリポジトリ以外のモデルは大体実装済み
- 日曜日までにリポジトリを阿部さんの方で作成いただく予定
チームコンテキスト
- チーム人事ファイルimportサービス以外のモデルを実装済み
- 日曜日はユースケースの動作を確認＋チーム人事ファイルimportサービスの実装

## 次回の日程
- 5/15 (日) 19:00~
- 松田（和）が参加できないので、mtgの進行を北浦さんにお願いしています。
- 進め方に関しては松田（和）の方で用意します。

# 添削者サービス 第4回オンラインコーディング

| 日付 | 5/2 |
| -------- | ---------------------------------- |
| 主催 | 松田(和) |
| 開始時刻 | 20:00 |
| 終了時刻 | |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 西川、阿部、藁谷、大鐘，中井，池側，松田(和)，松田(耀)，瀬尾，神保, 内藤(20:15~), 福田(21:00-)，畑中(21:30〜23：00)，北浦(21:30〜) |

## 実装の進捗、困ったことなど

チームビルダー チームのオブジェクトを作成、再構築
チームリポジトリ チームビルダーで作成したオブジェクトを渡して、永続化

内部の処理の流れを共有した方がいい（シーケンス図）

- 教務研究員
- メンバー
- 阿部、松田(和)
- ブランチ
- abe/examiner/domain-modeling
- 進捗
- 設計を再確認し、一般教務研究員と教務研究員リーダーを定義
- 困っていること
- builderを抽象インターフェースにすることが難しい
- 一般教務研究員とリーダー教務研究員で持つ属性が異なるため

- チーム1
- ブランチ
- ogane/feature/examiner/domain-modeling
- タスク
- 所属チームの追加と削除
- チーム仕様
- 進捗
- チーム配属サービス、チーム脱退サービスを定義
- 困ってるコト
- reconstruct_fromがなぜいる？
- DBのデータをオブジェクトの形に再構築する
- リポジトリに、DBからデータをとってくる責務がある
- 実装があってるか不安
- (松田耀)ブレイクアウトルームに分けなくてもいいのでは？という気がします。1人1人にタスクを割り当てた上で，同じliveshareを共有するとか？質問したときに答えられる人が多いほうが疑問点が解決しやすいですし。

- チーム2
- ブランチ
- 未定
- 進捗
- 特にありません
- 担当範囲の詳細を再確認
- 困っていること

- チーム3
- メンバー：畑中・池側・西川
- ブランチ
- （仮）team3/feature/examiner/domain-modeling
- 進捗
- 特にありませんでした．
- ``あるチーム職階(ex: リーダー)の教務研究員をまとめて取得``の実装する上でドメインモデルの図と対応付けのすり合わせを行っておりました
- 困っているコト
- これはTeam classから起点であっていますか？
- 単純のチーム3のメンバー間でこの仕様に関する状態遷移を理解しきれておりませんでいした...
- MemberRankSpecificationはclass定義でとどまっているがこれを使っていく認識であっていますか？

## 設計チームでの設計の流れの共有

1. 添削者サービスとして必要な機能を洗い出す
- それらの機能を満たせるような設計を考えていくという方針をとった。
2. 事前に、ある程度想定されるドメインモデル図を書いておく。
3. 個々のユースケースをドメインモデル図にあるドメインモデルで説明していく。
- 「洗い出したユースケース一覧」が例となっている
- 説明できなければ、ドメインモデル図が不適切と考えて、ドメインモデルの追加・修正を行う。（例：教務研究員を取得、永続化したいが、ドメインモデル図にリポジトリがない→教務研究員リポジトリを追加）
4. これを個々のユースケースに対して繰り返すことで、ドメインモデル図を完成させていく。
- 完成したドメインモデル図は下に記載してある

実装に関しての共有をお願いします。（中井さん、阿部さん）

### 設計の例

classDiagram
class チーム {
    配属(教務研究員) : None
}
class ITチーム
class メンバー
class 教務研究員

ITチーム --|> チーム : 実現
チーム *-- メンバー : 集約

1. 新規のメンバーをITチームに配属する
2. pass
3. **教務研究員**を**チーム**に**配属**すると、**チーム**が**集約**する**メンバー**に追加される
4. pass
5. ドメイン層だけのコーディング (main.pyとか1つのファイルに、この設計に出てきたクラス・メソッドだけを使ってコーディングしてみる. → 書き上げたユースケースをそれらのクラスを使って再現できる(`if __name__ == '__main__'`とかで))
* ドメイン層の設計はok
6. リファクタリングを行う. テストコードを書く
7. ドメイン層以外の実装を行う (できればTDD)

## これから行う作業

- 「洗い出したユースケース一覧」に従って、実装を行なっていく。
- 例えば、「(Q)教務研究員の所属チームを取得」という機能を実現する
- 上の機能に必要なドメインモデルを実装し、`if __name__=="__main__"`以下で機能を実装
- 本体実装ではなく、現状のドメインモデル図通りにドメイン層を動作させることができるかどうかサンプルを実装することで確認するのが目的。それにより、ドメインモデル図が確定。ここで実装ができないとすれば、ドメインモデル図を変更することになる。

### 開発の進め方
- サンプルコードの実装段階
- feature/examiner/domain-modelingブランチからfeature/examiner/{実装するモデル}という名前でブランチを切る
- プルリクエストはする必要あり？→基本出す
- VSCodeのLiveShareを使うと、ペアプログラミングしやすい

## 洗い出したユースケース一覧
QはQueryをCはCommandを意味している。
Queryはオブジェクトの取得など、結果を取得するが、システムの状態を変化しないもの。（副作用がないということ）
Commandはオブジェクトの修正など、システムの状態を変化させるもの。（副作用があるということ）

* (Q)教務研究員の所属チームを取得
* 教務研究員に対応するメンバーが所属するチームを取得する
* チームのselect_satisfyingで取得
* メンバー職階仕様が検索条件を表現する
* サブマネのメンバーを取得したい場合はサブマネ検索用のメンバー職階使用を渡せばよい
* チームは化学チームのような粒度ではなく、化学添削者チームや化学リーダーチームのような粒度で分けられている
* (C)所属チームの追加・削除 : Team1
* 追加：　~~チーム配属サービスにチームと教務研究員の情報を渡して、メンバーファクトリによってメンバーを作り、その後メンバーを教務研究員とチームに持たせ、メンバーリポジトリに格納する~~
* チームのassignを使用
* あるエンティティの責務内で実行可能な処理は，サービスを新規に作るのではなく，エンティティのメソッドとして定義。
* assignの引数は「N0489752」などの単なるstring，教務研究員コンテクストの教務研究員インスタンス属性ではない。(コンテクストが別れたらインスタンスは共有しない)
* ~~削除：チーム脱退サービスにチームと教務研究員の情報を渡して、チームと教務研究員からメンバーを削除する~~
* チームのexpelを使用
* (Q)教務研究員を取得
* 教務研究員リポジトリからsearch_by_仕様
* (C)教務研究員の追加
* 教務研究員追加サービスに必要な情報を渡す
* 教務研究員ビルダーで教務研究員を生成
* (C)教務研究員の削除
* 教務研究員削除サービスに必要な情報を渡す
* (C)教務研究員リーダー職階の変更（更新）
* 教務研究員リーダー人事読取サービスでリーダー人事を読み取り教務研究員リポジトリに渡す
* 教務研究員リーダー職階：人事チャンネルでの職階
* チームでのメンバー職階：チームごとの職階
* slackの人事チャンネルからリーダー人事のテキストを読み取るためのサービス
* (C)メンバー職階の変更：Team2
* チーム人事ファイルimportサービスでファイルを読み取りメンバーリポジトリに渡す
* 豊本さんが持っているexcelのファイルを読み込むためのサービス
* この際、人事制約を参照し、例えばリポジトリにアクセスして「いつ現在の職階になったか」などの制約条件を確認した上でメンバー職階を変更するなどのユースケースに応えられる
* 他にも、AIチームのように稼働時間に制約がある場合も、日報サービスにアクセスして...という処理を実装可能
* (C)リーダー→一般教務研究員に変更
* 逆推挙サービスにリーダーを渡す
* (C)一般教務研究員→リーダーに変更
* 推挙サービスに一般教務研究員を渡す
* 一般教務研究員クラス→教務研究員リーダークラスに変更することで変更を行う
* (Q)あるチームのあるメンバー職階(ex: リーダー)のメンバーをまとめて取得 : Team3
* チームのsearch_by_仕様メソッドにチームリーダー仕様を渡す
* (C)チームの追加
~~* チーム追加サービスに必要な情報を渡す~~
* チームビルダー
* 新規生成
* DBのレコードからオブジェクトを再構成
* チームリポジトリ
* 永続化
* レポジトリ(レポジトリがビルダーを持つ)のメソッドとして実装

## 設計チームで考えたドメインモデル図


* チームは化学チームではなく、化学添削者チームや化学リーダーチームのような粒度で分けられている


## リポジトリの構成

- api:
- services:モジュラモノリスでサービスを管理。コンテキスト単位でコードを管理。
- domains：mainにドメインモデルを実装している
- appricatons
- infrastructures

### コードの注意点
- クエリとコマンド
- クエリ
- 変更なし、返り値あり
- コマンド
-
- 変更あり、返り値なし
- 変更しつつ返り値返すのはダメ
- 抽象クラス
- インスタンス化はしない
- 継承されるためにインタフェースを定義するもの
- Builder
- new
- 新規追加
- reconstruct_from
- DBから復元
- Repository
- メソッドはclassmethodで
- (理由)Repositoryはインスタンス化したくない。インスタンス化すると、DBとの接続をそのたびにしなきゃいけないから。
- クラス変数
- あるクラス内で別のクラスをインスタンス化したいときは、"わざわざ"クラス変数に登録する
- (理由)クラス変数を見るだけで、依存性がわかる。拡張性もよし。

### チーム1
* チームコンテクスト
* 所属チームの追加と削除

### チーム2
* メンバー職階の変更

### チーム3：あるチーム職階(ex: リーダー)の教務研究員をまとめて取得
* メンバーのreconstruct_fromのassined_atの引数の対処
* 一度MemberBuilderでメンバーインスタンスを生成してみて動作確認を行う．
* メンバーに職階を付与するドメインは？
* ImportMemberRankFileService機能？

# 添削者サービス 第3回mtg

| 日付 | 4/16 |
| -------- | ---------------------------------- |
| 主催 | 松田 |
| 開始時刻 | 13:00 |
| 終了時刻 | 16:30 |
| 場所 | Zoom |
| 参加人数 | 5名 |
| 参加者 | 内藤、遠藤、畑中、西川、阿部 |

## 要件定義を修正
- 修正は第2回mtgに追記している

## 疑問点
- 差し戻し用のslackChIDというのは、個人チャンネルのこと？（返却pj）
- 返却開始日というのは、入社日ではなく? （返却pj）
- 新たに返却開始日を追加するとすると、添削者サービスが持ちそ
- あるリーダーの日報報告可能なチームの情報(日報pj)
- あるリーダーの所属チームが辿れればOK?

## ITチームとしての方針
- 現在進めている3サービスに関しては、中井さんと阿部を含め、今後設計を主導していきたい直近で動ける方で設計を終わらせる
- 上記に参加しない方も、4/30までに最低限のDDDに関する知識を「各サービス内での資料の輪読会」により持っていただく。
- [輪読会資料](https://hackmd.io/Dp3luPVWRhWK1DU63i8Hlw)

# 添削者サービス内オンラインコーディング 第2回

| 日付 | 4/11 |
| -------- | ---------------------------------- |
| 主催 | 松田（和） |
| 開始時刻 | 20:00 |
| 終了時刻 | 22:40 |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 中井 阿部 大鐘 西川 畑中　福田　松田(耀)　北浦 瀬尾(20:30~) 内藤(20:45~)|

## 要件定義

### 添削者サービス 返却pj、日報pjからの要望

添削者サービスの概要
[設計mtg #1](https://hackmd.io/OpxAhc_zSMK2uC4SmvnWWA)

#### 返却pj

- 添削者サービスの利用目的
- 添削者の情報を取得すること

- ユースケース
- 添削者の各種情報を取得すること
- リーダーの各種情報を取得すること
- リーダーについては別のサービスで扱うのであれば必要ない

- 実装してほしいこと
- 返却PJで（将来的に）読み取りたい添削者に関するデータについて
- 添削者
- 添削者ID
- 科目
- slackUserID
- 差し戻し用のslackChID
- （添削者評価）
- （担当大学）
- （添削開始日）
- すべて添削者サービスがもつ必要はないとは思います。
- 読み書きしたい添削者に関する情報もありますが、それについては返却PJ内で持つつもりです。
- リーダー
- 添削者ID
- 科目
- （添削者WSの）slackUserID

- APIを通して取得できるように

- データの境界に関して
- 添削者のslack周りの情報について、slackと添削者のどちらが持つか
- 差し戻し用のslackchについて、添削者と返却PJのどちらがもつか
- 添削者に関する種々の情報についてどこまで添削者サービスが持つのかの基準

#### 日報pj

- 添削者サービスの利用目的
- リーダー - チームの情報取得

- ユースケース
- ここにあるリーダー(6桁ID & 氏名)じゃないと、日報申請できないというバリデーションをかける
- あるリーダーが所属しているチームのみ日報申請できるようにする
- 例えばAさんは物理とITに所属している場合、物理、IT以外の日報を登録する必要はない
- 現状LIMEでは、全チームできちゃうのが微妙
- そのために各科目やチームの方には、あらかじめLIMEからチームに登録してもらう必要がある。
- /teams/{team_id}/examiners/{examiner_id}のPOSTかな？
- チームごとに誰が登録できているか見れる必要あり
- /teams/{team_id}/examinersのGETかな？

- 実装してほしいこと
- 上に書いた通り
- LIMEでチーム登録できるようにするところまで実装が必要
- そのためにAPI化する必要あり

- データの境界に関して
- あるリーダーの日報報告可能なチームの情報は、添削者サービスがもつ
- examiner-teamsでよさそう
- 日報報告channelの情報はSlackサービスがもつのか、日報がもつのか
- 一つのチームに対し、複数のchannelを日報報告channelに選べるように

## データの境界

- 主な目的
1. 添削者ID-名前のリストを管理する
2. 添削者の所属チームを管理する
3. 添削者の所属チーム内での職階を管理する
4. 添削者の所属科目を管理する
- 持っておくべきデータ
1. 添削者を一意に特定するID ルーム1
- 添削者エンティティ
3. チームを一意に特定するID ルーム2
- 添削者-チームエンティティ
- チームエンティティ
5. 科目を一意に特定するID ルーム3
- 添削者-科目エンティティ
- 科目エンティティ
7. 職階を一意に特定するID ルーム4
- 添削者チーム-職階エンティティ
- 職階エンティティ

## 考えられるユースケース

- 管理するリストはどのようなシチュエーションで必要になるか
- 管理するリストはどのように更新されていくのか
- 「持っておくべきデータ」がどういうユースケースにどのように使われるのか
- ...

### 添削者

添削者の定義
- 氏名: 東進 太郎
- ID, teamIDの処遇
- 人1に対して、IDが2つ以上あった場合
- 人が特定されたが、IDが複数あって、どっちを選べばいいかわからない状態があるか
- N0123456やteamIDなどのid系はシリアルで別で管理
- このID系と(氏名)を多対1でひもづけ
- 人とアカウントを区別して管理する
- 添削者IDとteamIDは並列でみる
- ID系は添削者-科目のところに追加する

ユースケース
- 研修
- 各科目の新規添削者研修担当のリーダーがまず関与する
- 返却/振り分け
- IDと添削答案の結びつき
- 可能工数登録はIDごとに行うし、振り分け先もIDごと
- 個人に結び付けない
- 添削者評価
- 添削者と評価値の結びつき
- 評価はIDに結び付けて、人にはつけないのがよさそう
- 日報
- 申請時の(ID, 氏名)の組み合わせでバリデーション

- 逆に「人」に結び付けないといけないもの
- 最終的な単価
- 月ごと
- 科目横断的なブラックリスト・ホワイトリスト？
- 採用の段階で入ってくる情報
- 所属大学・学部
- 変わりうる
- 年1更新
- 学年
- 毎年変わるのは少し厄介？
- 年1更新
- 性別
- 変更なし
- メアド
- 変更なし？
- 入社日
- 変更なし
- 退社日
- ガチで東進から身を引く場合に記録
- IDごとのものとは別
- 例えば、兼任してたところをやめる場合は、こおはそのままで、添削者-科目エンティティの方でやめたことを記録するとか

管理するリストの更新頻度・方法
- 新規追加
- 最終選考会通過後，自動で入るようにしたい(採用研修委員会のリーダーがやる？)
- 更新
- ngsIDが変更されることはない(同一人物の再雇用はある)
- 兼任添削者(英語と日本史，など)の場合同じN0+6桁のIDを使う or どちらかでteam+3,4桁のIDを使う
- 削除
- 退職時
- 影響範囲
- レコードとしては残すべき
- いつ入って、いつ抜けたかという情報をつけることで削除を表現

### チーム

チームの定義
- IT、TDU、SKK、各科目、...
- 日報の作業コードに基づく分類
- 多くの添削者は「科目」と重複する
- 科目 ⊂ チーム

ユースケース
- 日報の業務区分（作業コード）、検証
- 所属チームのみ日報申請
- 職階の情報も必要
- メンバーがどのチームに参加しているか検索したい
- チームに参加したら、自動でチームのSlackWS招待
- チームごとに管理されるもの
- SlackWS（多）
- Backlog(通常1)
- チーム単位の作業
- 月例報告など、全員に対する指示の進捗管理
- 研修の管理

管理するリストの更新頻度・方法
- チームの追加削除
- ほぼ更新のないため、IT側で対応
- メンバーとチームの紐づけ
- 多-多
- リーダーが登録
- メンバーを登録する際に科目と同時に登録
- 退職の際に削除
- 過去のデータを残しておくか？
- created_date,updated_date,deleted_date

要検討
- チーム、メンバーのSlackWS,ID管理
- Slackサービスで持つ？
- チームごとに職階が異なる可能性があるのではないか
- チーム-添削者-職階で結びつけ
- 科目とチームを分ける意義
- 管理POSなどは科目を主に使用
- 科目とチーム、分けたままで

### 科目

科目の定義
- 国語,数学,英語,物理,化学,生物,地理,日本史,世界史,公民,小論文,答練理科,...
- 過去問PJ上の数字とかは一旦結びつけないことにして、serialで考えておいた方が良い

逆に科目じゃないもの
- 添削者に結びつかない
- 四谷算数,...
- SKK,制作,返却,... (こっちはチーム)
- 管理したい場合は別で管理するべき

- 日報の場合は業務区分は「チーム」なので使わない
- 返却の場合は添削者に結びついた「科目」の情報が必要. 返却は答案を絞るのに使う.
- 振り分けの場合はPULLPOOL答案ダウンロード、答案振り分け、一括更新など
- 添削者評価
- 管理POSで添削者名で順に絞る場合
- POS負荷軽減
- opstts,tgtを使う場合
- 処理の軽量化
- 遅延催促
- 答案を絞る
- 工数分析
- 処理の軽量化
- 科目兼任
- 多-多である必要
- teamIDは一般の添削者と同じ扱い. 例えばN0432629=team804だったとしても、このマッピング情報は添削者サービスの責務では有しない
- 試験種決定最適化
- 処理の軽量化
- 模試
- 採点者評価・校閲者評価の送信先として使用する
- 科目マスタが変更されることはない
- 科目-添削者が変更されることはある
- その科目の研修担当者に確認し、大丈夫であれば移籍する
- この変更の副作用はない
- サービスが提供すべきインターフェースとしては「指定した添削者の属性の1つの科目を書き換える」
- 科目も添削者もエンティティ

新規作成
- 添削者名等と同タイミング
更新
- 移籍の際に必要(兼任は不要)
- 手動
- 科目登録スプシによる自動化
- brosアカウントなので、botが動くか
- 移籍フロー(化学科の例)
- 他科目→化学科の受け入れ
- 他科目の人からメンションがきて、受け入れ可否を聞かれるので、基本受け入れて問題ないです。過去に僕が送っているメッセージをそのまま送れば問題ないと思います。
- 化学科→他科目の移籍依頼
- 科目内で移籍したい人が出てきたら、科目移籍ホットラインで該当科目の担当者をメンションして、a. のように連絡を取ります。
- このときは豊本さんに連絡する必要があります。リーダーWSの# b03_添削者の科目登録について というチャンネルで移籍を報告します。チャンネルにやり方が記載されているので、その通りに報告します。

### 職階

職階の定義
メンバー,サブマネージャ,マネージャー,リーダー,上級リーダー(リーダーチームの職階)
メンバー以外は基本的にリーダー

- 職階の更新
- リーダー：人事を決めるタイミング
- リーダーの登録
- リーダーとして雇用したタイミングでLIME上でリーダー登録するなど
- チームに所属していれば何かしらの職階になっている
- デフォルトはメンバーで登録される想定
- リーダーは毎月の人事以外で追加はされないので、それ以外のフローでチームに所属する場合はメンバーになる
- その添削者がリーダーかどうかの判別
- あるチームの特定の職階のメンバーを取得
- (あるチームのリーダーを一覧取得)
- (あるチームのメンバーを一覧取得)
- 例えば兼任しているリーダーであれば、それぞれのチームでの職階がそれぞれのチームに紐づく形で保存される
- 職階を更新した際の日付情報を保持するか？
- 職階+更新日で保持し、過去の時点での職階も保持する(人事が変った際は更新ではなくレコードを追加する形で)
- リーダーから抜けて添削者にもどる場合はメンバーとする．
- この場合、職階として「チームから抜けた」ことを表すものが必要になる
- もしくは現在の職階のみ保持し、過去の職階は上書きするか
- チームから抜けた場合はレコードを削除
- ユースケース的に前者の方が良さそう

## 各エンティティに結びつきうるデータ

### 添削者

#### 旧案

- 添削者エンティティ
- [添削者サービス]PK : 添削者を一意に特定するID (ユーザーID)
- [添削者サービス]氏名
- ~~最終的な添削単価~~
- 科目ごとに違う
- 添削者-科目エンティティでもつ
- 採用の段階で入ってくる情報
- ~~担当種別~~
- 答練専任or答練兼任or答練未担当
- 科目に入れる(答練数学など)
- [添削者サービス]所属大学・学部
- 年1更新
- [添削者サービス]学年
- 年1更新
- [添削者サービス]性別
- [添削者サービス]メアド
- [添削者サービス]入社日
- [添削者サービス]退社日

※退社日：ガチで東進から身を引く場合に記録。兼任をやめる場合は含まない。

#### 新案
→ 添削者とリーダーのエンティティは(持つべき属性が異なるので)やはり別に持ちたい→別々のエンティティを用意し、社員（教務研究員）エンティティと関係付ける

- 添削者エンティティ
- [添削者サービス](チームエンティティの)チームID、添削者id
- [slackサービス]slack id（複数）
- [添削者サービス]created at
- [添削者サービス]deleted at
- リーダーエンティティ
- ~~[添削者サービス]職階~~
- [添削者サービス]所属チーム
- 教務研究員エンティティ
- [添削者サービス]PK: 添削者id(例: N0123456)
- [添削者サービス]氏名

### チーム

#### 旧案
- 添削者-チームエンティティ
- [添削者サービス]PK : サロゲートキー
- [添削者サービス]チームID
- [添削者サービス]添削者を一意に特定するID（ユーザーID）
- [添削者サービス]職階 (チームと組み合わせてチーム職階に. どの時点でどの職階だったかを追える必要がある)
- ([採用サービス]CBTテストの点数 雇用時の情報なので最初の設計からは除外)
- [slackサービス]slack id（複数）
- [添削者サービス]created at
- [添削者サービス]deleted at
- チームエンティティ
- [添削者サービス]PK : チームID(連番)
- [添削者サービス]チーム名(IT,数学,TDU,...)
- [過去問PJサービス]日報の作業コード(73,30,31,...)
- [backlogサービス]BacklogチームID
- [backlogサービス]BacklogプロジェクトKey
- [slackサービス]slack ws（複数）

#### 新案
- 添削者-チームエンティティ
- リーダー-チームエンティティ

添削者エンティティを、添削者エンティティ、リーダーエンティティ、教務研究員エンティティにしたことにより、

### 科目

- 科目には答練理科なども.

~~- 添削者-科目エンティティ
- [添削者サービス]PK : サロゲートキー
- [添削者サービス]添削者ID
- 答練専任or兼任or答練未担当(`添削者`の担当？)
- [振り分けサービス]担当試験種(リスト)
- [添削者評価サービス]添削者評価
- [模試サービス]模試採点者評価・校閲者評価
- [振り分けサービス]可能工数
- 見込みの可能工数
- [返却？添削者評価？サービス]遅延・差し戻し・剥がし数
- [答案管理サービス]添削中答案
- [添削者評価サービス]添削単価
- [答案管理サービス](添削済工数)
- [振り分けサービス]希望の試験種
- (VIKING取得上限)
- [slackサービス](slack 個人pvch id)
- [過去問PJサービス]uid
- [振り分けサービス]上限工数~~
（理由: ・添削者-科目の関連の属性もほとんど異なるサービスのものなので、属性は不要かも (社員-科目でないことに注意)）
- 科目エンティティ
- [添削者サービス]管理pos上での科目ID
- [添削者サービス]IT独自の値
- [添削者サービス]科目名
- [振り分けサービス]試験種(リスト)

※添削単価：過去のものも持つ？
- 添削者評価は評価を決めてて、単価を決めてるとはいえない？
- 添削済み工数と添削単価から計算したい場合がある
- 結論
- 工数分析にするのは違和感なので、添削者評価に

### 職階

~~- 添削者チーム-職階エンティティ(あるチームに所属する添削者がいつどの職階にいるか表すテーブル)
- 添削者-チームエンティティのPKであるサロゲートキー
- 更新(登録)日
- 職階ID
- ~~
- 職階エンティティ
- [添削者サービス]職階ID: 連番
- [添削者サービス]職階名：str
- チーム-職階エンティティ
- [添削者サービス]PK : 連番
- [添削者サービス]チームID : 連番
- [添削者サービス]職階ID: 連番
- [添削者サービス]時給

# 添削者サービス 第1回mtg

| 日付 | 4/6 |
| -------- | ---------------------------------- |
| 主催 | 松田 |
| 開始時刻 | 21:00 |
| 終了時刻 | 21:50 |
| 場所 | Zoom |
| 参加人数 | 10名 |
| 参加者 | 西川、畑中、大鐘、池側、内藤、阿部、中井、福田、北浦，松田(耀)(21:30~)|

## 自己紹介
|メンバー|開発経験(何でも)| 役割 |
|-- |--- | --|
| 松田（和） | 工数分析pj 汎用db開発 Slackpjなど |タスクマネージャー|
| 中井 || 設計 |
| 阿部 |色々(主に管理POS,DB,工数分析)| 設計 |
| 池側 |DBpj, 添削マクロpj| DB |
| 大鐘 |LIME,Backlog,他チームのWebページetc...| UI |
| 藁谷 |添削者評価pj,科目での添削者評価プログラム||
| 内藤 |ナガセでは経験なし||
| 西川 |添削マクロpj, 添削者評価pj||
| 福田 |DBpj,添削マクロpj||
| 松田(耀) |返却pj,データベースpj||
| 北浦 | 試験種決定最適化、Backlog ||
| 畑中 |主にデータベースpj|？|

## 概要説明(昨年度からの変更点など)

- サービス分割をきっちり行う
- DBやデプロイなどもサービス内で行う
- ITチームとして、メインはサービス（添削者サービス、slackサービス、過去問PJ）
- このチームの皆さんは、添削者サービスの業務に注力していただきたい(基本的に兼任はない方針)
- 科目チームとの連携を強化
- サービスのmtgに科目リーダーの方が参加していただく形
- クライアントが外部にいる場合は特に
- このサービスは基本的にITチーム内で完結しそうなので、現状は行わない
- 設計の方針決めは中井さん、阿部さんに行っていただく
- メンバーの方には、これから業務を進めていく中で、知識を吸収していただき、設計に関われる人材になっていただく形
- PMについて
- リリースまでの期日を逆算してスケジュールを立てる
- 科目チームと密に連携を取る、窓口になる(科目への状況説明、mtgへの参加など)
- slack上だけではなく、サービスのmtgに参加していただくようにするなど
- メンバーの工数把握、タスクの割り振り・進捗管理・催促
- 今までのPMとの違い
- 積極的に行わなくてよいこと
- 設計的な方針決め(API設計どうするか？とか→それぞれの担当者が指揮する)
- 一点集中を防ぐ
- マネジメントと技術的な担当者をわける
- 各担当者について
- 例えば、DB担当の方にはDBに関しては丸投げ、という形ではなく、DBに関する業務を指揮していただく形
- なので、メンバー全員が設計、DB、フロントエンド、バックエンド...に関わっていくことになる
- 自分の担当範囲に関しては自分が責任を持つようにする(主体的に動く)
- メンバーというよりは1サービスの1タスクを担うという責任を持っていただく
- mtgについて
- 　従来のようなmtgはなくなり、サービスとして週1回で各4~5hのオンラインコーディングで完結するようにする
- ITチーム全体として土曜の午後(4~5h)に全PJ同時(最初にメインセッションで連絡事項共有→サービスごとにブレイクアウトルームで会議やコーディングを行う)
- 人数は多いので、コーディングできる人と苦手な人でペアプログラミングのような形を考えている
- 全体の方では他PJとの連携や質問対応に充てる
- 個別の方ではPJ内での割り振りやリファクタリングなどに充てる

## オンラインコーディング　日程調整

ITチーム全体として、毎週土曜日 13:00~18:00 ? 初回は16日から

添削者サービスのオンラインmtg

一番参加人数が多いのは4/13(水) 21:00〜
しかし、slackサービスと被りそうなので、
4/11(月) 20:00〜の方が良さそう

[添削者サービスのオンラインmtg日程調整](https://chouseisan.com/s?h=1d49e7d9b9cb46d09ab9891c47b1ca8d)

## 全体のスケジュール案

**4月中に終了**

- 全体の工程
- 要件定義
- ソフトウェア設計
- ドメイン層
- アプリケーション層
- インフラ層
- API設計　（OAS作成など fastapiなら自動作成できないのか？）
- DB設計
- テスト作成
- CI構築(github actions)
- CD構築(マスタブランチから本番環境への自動デプロイの準備)
- 本体実装

- 4/6(今日)
- 4/11~15 (添削者サービス)
- 要件定義
- ユースケース洗い出し
- データの境界決定
- 4/16(ITチーム全体)
- 要件/ユースケース/データの境界の発表と共有
- ドメイン設計
- 4/18~22 (添削者サービス)
- アプリケーション層
- インフラ層
- API設計
- DB設計
- 4/24(ITチーム全体)
- テスト作成
- 4/25~29 (添削者サービス)
- テスト作成
- 本体実装
- 4/30?(ITチーム全体)
- 本体実装

フレームワーク fastapi

- リポジトリはnagaseitteamの[it-service](https://github.com/nagaseitteam/it-service)を使用
- ITチーム全体で使っていくリポジトリ
- docsにはOpenAPIを書いていく
- https://github.com/nagaseitteam/it-service/tree/features/kpj_interfaces
- API
- servicesが各PJに作ってもらう(ディレクトリ構造含め)
- api/services/(添削者サービス用のディレクトリ)で開発
- api/test_services/(添削者サービス用のディレクトリ)でテスト作成
- https://github.com/nagaseitteam/it-service/tree/features/docs_kpj

## 要件定義

- どこまでを担う？どのデータを保持してどのデータを拝借する？
- ユースケースの洗い出し
- 提供すべき要件の洗い出し
- 明確にデータの境界を決める

ドメインモデリングとか調べておくと役に立つのでは？

## 次回のオンラインコーディング

4/11(月) 20:00~

# 添削者サービス 第0回mtg

| 日付 | 4/3 |
| -------- | ---------------------------------- |
| 主催 | 松田 |
| 開始時刻 | 11:00 |
| 終了時刻 | 12:00 |
| 場所 | Zoom |
| 参加人数 | 3名 |
| 参加者 | 阿部 中井 |

## はじめに(slackのコピー)
- 昨年度の開発では設計を疎かにしてしまっていた
- 保守性の悪いものしか出来なかった
- 今年度は設計をみっちりとやる
- サービスの分割を明確に
- それぞれのサービスがどこまでを対象とするか？
- DBの設計もPJの範囲内で収まるように
- 昨年度は10PJの並行に対してノウハウを共有出来ていなかった
- 本年度は小数のPJを有識者が見ている中で進める、開発経験を積むことで状況を打開する
- slackに関して
- 各添削者情報やbot情報などがバラバラにならないように
- 重要なのはどこにデータの境界を置くか？
- eg)slackは添削者に関する情報を扱うサービスの下流に位置する
- 設計の段階でそのあたりの考えを組み込む(外部拝借と内部保持)
- 設計にはオブジェクト指向・DDDの知識を前提とする
- 昨年度はその知識を持たないまま進めてしまった
- 今年はここをまず重要視する
- 阿部さん中井さんが設計を引っ張りながら進める→コードベースで全員でコーディング、DBの設計、APIの設計書書いたうえでUI担当と協力しバックエンドとフロントエンドを協力する
- ここまでを**4月中**に終わらせたい
- 今までの流れだと無理そう
- 本年度はまずPJの兼任を原則廃止し、進捗管理を楽にする
- **ITチームとしてのメインはサービスということをメンバーに周知する**
- とりあえずこのPJを最優先にする！
- ∵それぞれの技術を理解できる人を増やす、OJTの意味合いを含めている
- 科目リーダーとの連携の弱さ
- 月一で代表者と話す？上手く行かない？
- 結論→3サービスについて各科目からリーマネをアサイン
- 設計の評価等を行ってもらう
- 週1で成果物共有(科目+サービスメンバ)、週1でマイナーバージョン更新と共有はしたい
- リリース前や設計段階に過不足を指摘してもらえるメリット
- 添削者サービスではとりあえずなし(ITチーム内で完結しそうなため)
- 直接のクライアントがいない(ITチーム内で使うもの)
- 振分とか返却とかでは必ず必要なフロー

## タスクマネージャーについて

- タスクマネージャーとしてのPMの立ち位置
- リリースまでの期日を逆算してスケジュールを立てる
- 科目チームと密に連携を取る、窓口になる(科目への状況説明、mtgへの参加など)
- slack上だけではなく適宜mtgの開催(基本週1)
- 添削者サービスに関連する科目チームはどのチームになるのですか？（松田）
- サービスごとにmtgを設定するのか、合同で設定するのかどちらがいいですかね（松田）
- メンバーの工数把握、タスクの割り振り・進捗管理・催促
- 今までのPMとの違い
- 積極的に行わなくてよいこと
- 設計的な方針決め(API設計どうするか？とか→それぞれの担当者が指揮する)
- 一点集中を防ぐ
- マネジメントとテックリードをわける

## 添削者サービスとしての順序(slackのコピー)
- 要件定義
- どこまでを担う？どのデータを保持してどのデータを拝借する？
- ユースケースの洗い出し
- 提供すべき要件の洗い出し
- 明確にデータの境界を決める
- ソフトウェア設計
- 最初にドメイン層の設計(サービスのコアになる機能)
- 添削者に結びつく形でのslackID、WS所属情報を取得する
- WSから添削者の情報を取得できるように
- chはWSというルートの下に行く設計(DDDを元にした考え方)
- この段階をメンバーに共有することで、設計の重要性をITチーム全体として理解する
- ここまでではAPIとしての機能を果たさない
- アプリケーション層の設計
- ドメイン層の組み合わせ
- 実際のユースケースの粒度に合わせた機能の提供
- API経由で使えることよりも直接import出来る方が望ましい、他プロジェクトのユースケース粒度に合わせる
- 他プロジェクトに関してはドメイン層の粒度を考える必要があるかも
- インフラ層の設計
- サーバーを立ててAPIを実装、DBの入出力のためのインターフェース
- API設計
- 下にかいてある通り
- 今は必要そうなテーブルを設計しただけ、中身はブラックボックス
- DB設計
- 他のPJとの共有・切り離しの決定が重要
- コンテキストマップの準備(境界付けられたコンテキストでggる)
- 直接他のPJのキーを引っ張ってくるとコード番号の変更などに弱い
- 影響範囲をマッピング部分のみに留める
- 単純にやると事故る
- 開発範囲の分担
- テスト駆動開発(テスト作る→本体実装)
- (CI)github actionの準備 (阿部さん)
- (CD)マスタブランチから本番環境への自動デプロイの準備 (阿部さん)
- 決めた仕様通りに開発
- 1,2週間程度で一気にやる
- アジャイルに機能追加や修正
- バックエンドだけではなくてフロントエンドも同時に開発する
~~- 1週間ごとに成果物の共有と意見交換のmtg開催~~

### 注意点
- 技術レベルでタスク分担をしない
- DB担当・API担当やバック/フロントエンドという分け方はしない
- タスクごとの切り分けを行う
- 人数は多いので、コーディングできる人と苦手な人でペアプログラミングのような形にするとよい
- **mtg頻度**
- 科目との打ち合わせmtgは週1程度(自PJでのコーディングと同日でもよい)
- slackに関してはあまり週例化しなくて良さそう
- オンラインコーディングを週2程度(週例mtgは廃止)
- 1回で4,5時間・設計からコーディングまで
- ITチーム全体として土曜の午後に全PJ同時(最初にメインセッションで連絡事項共有→サービスごとにブレイクアウトルームで会議やコーディングを行う)
- 週1でPJごとのコーディング時間を作る
- この2回を通して密に連携して欲しい
- 全体の方では他PJとの連携や質問対応に充てる
- 個別の方ではPJ内での割り振りやリファクタリングなどに充てる

## 添削者サービスの設計案（設計mtg#1からの抜粋）

### ver1. 添削者・チームの追加

* /examiners
* 添削者一覧
* /examiners/{examiner_id}
* 添削者詳細
* /examiners/{examiner_id}/subjects
* /examiners/{examiner_id}/teams
* /subjects
* 科目一覧
* /subjects/{subject_id}
* 科目情報の詳細
* /subjects/{subject_id}/examiners
* 科目に含まれる添削者一覧
* /teams
* チーム一覧
* /teams/{team_id}
* チーム詳細
* /teams/{team_id}/examiners
* rankでquery可能
* /teams/{team_id}/examiners/{examiner_id}
* チーム内での(ランクなどを含む)添削者情報
* /ranks
* /ranks/{rank_id}

erDiagram

examiners {
	p_id integer
	uid string
	name string
}

subjects {
	p_id integer
	name string
}

teams {
    p_id integer
	name string
}

examiner-subjects {
    pf_examiner_id integer
    pf_subject_id integer
}

examiner-teams {
	pf_examiner_id integer
	pf_team_id integer
    f_rank_id integer
}

ranks {
    p_id integer
    name string
}

examiners ||..o{ examiner-subjects : in
subjects ||--|{ examiner-subjects : have
examiners ||..o{ examiner-teams : in
teams ||--|{ examiner-teams : have
ranks ||--|{ examiner-teams : have

* subject : 添削を行っている単位
* team : ほぼ業務IDと同じ区分
* ranks : メンバー, ...

## TODO
- ITのgithubにメンバーを招待
- itserviceというリポジトリが今後ITチーム全体で使っていく
- docsにはOpenAPIを書いていく
- API
- servicesが各PJに作ってもらう(ディレクトリ構造含め)
- kpalにテンプレがあるので参考にする
- 初回mtgで決める事
- PJ毎のオンラインコーディングの時間帯の決定(序盤はmtgだと思えばよい)
- 各担当者の立ち回りを意識させる
- 受け身じゃないよ
- 自分の担当範囲に関しては自分が責任を持つようにする
- メンバーというよりは1サービスの1タスクを担うという責任を持たせる
- 設計の重要性の認識
- 学習資料準備中
- 最初の方は主導していくのでゆくゆくは自分たちで設計できるように！！
- 一旦松田がこの流れを理解する
- その上で重要な部分を明確に
- どこまで伝えるかの裁量はPM次第