# アーキテクチャ

- システムアーキテクチャ
- アプリケーションアーキテクチャ

ひとまず，以下 2 つのフェーズについてのアーキテクチャを考えた．

- 初期の MVP の開発フェーズ
- ユーザの増え始め，跳ねに備えるフェーズ

## システムアーキテクチャ

- 初期
- Amazon EC2 上に Docker Compose で全部のせ
- Web: Nginx
- AP: Python/Flask
- DB: MySQL
- AWS
- Amazon EC2
- Amazon S3
- メリット
- 何も考えなくず，各コンポーネントを EC2 に載せるだけでよいから本番環境を整えるのが楽
- 低コスト
- Docker Compose によりローカル環境での開発が容易
- デメリット
- スケールしにくい
- アクセスが集中したら捌けなくなる恐れがある
- DB が分離されていないのでデータ量が増えてきたらインスタンスのスペック自体を増さないといけない
- 可用性がない
- ステージング環境がない
- セキュリティも甘い
- ユーザの増え始め，跳ねに備えるフェーズ
- サーバの複数台に分割
- DB を他のサーバ or マネージドサービス（Amazon RDS など）に分離
- マネージドサービスの場合，バックアップが容易になる
- Web/AP の部分をオートスケールにしてアクセスの急増に備える

## アプリケーションアーキテクチャ

- 初期
- 最低限の責務の切り分けをする設計
- ビジネスロジックと DB 接続部分を分ける
- メリット
- 開発速度が速い
- デメリット
- 実装の
- ユーザの増え始め，跳ねに備えるフェーズ
- レイヤードアーキテクチャ（クリーンアーキテクチャ）
- メリット
- 開発初期段階で DB へのモックが簡単に差し込め，フロント側の実装にも困らない
- テストがしやすい
- どこに何が書いてあるのかが把握しやすい
- デメリット
- 設計に時間が必要

---

## 実装中に考えていたこと

## 設計について考えていたこと

- 環境構築の容易さ（再現性，ポータビリティ）から，ハッカソンなら Docker Compose だろうと思っていた．
- 意識したのは「責務の分離」．プロジェクトが小さいため細かくディレクトリなどを分けることは少なく，基本的に 1 ファイル 1 つの役割，という考えでファイルを分割していた．
- データモデルとシリアライズ，
- プロジェクト自体が小さく，編集する箇所もかぶることが多いため，どうせコンフリクトが生じるから起きたら直せばいいやくらいで考えてた．

## 失敗したこと

- Flask，ORM 周りを「ちょっと触ったことあるからなんとかなるやろ」くらいで思っていたら結局ツールを調べる時間の方が多くなってしまった．
- 始めに API のテストを書き（リクエスト，レスポンスの情報を定義くらいでも良い），フロントエンド側とすり合わせをしやすくすべきだった．お互いの実装が進んだ後にすり合わせだとどちらかが合わせなければいけなくなってしまい，申し訳なかった．

## 良かったこと

- ドキュメントを丁寧に書いた．お互いの技術力を少しずつ知っていくという過程の中で，開発時の齟齬が起きないように情報の共有に気をつけた．（書くのが好きなので自己満といえば自己満）
- コミュニケーションを積極的に取れたこと（というより，チームメンバーが発言してくれる方が多く非常に助かった）

## 反省

- 「触ったことある」は「実装できます」じゃない．ハッカソンは持っての他．メンバーが不幸になる．（自分が西原さんにやってしまった）