目次
1. 機能一覧
2. テーブル設計
3. 工夫した点
4. 振り返り
① 機能一覧
- TOPページ (メモ一覧)
- メモ登録ページ
- ブログ編集ページ
② テーブル設計
③ 工夫した点
(1) ドメイン駆動設計
メモの作成、編集などのビジネスロジックはUseCase層のInteractorに委譲しControllerは、リクエストの受け取りやレスポンスの返却に集中させることで責任を明確化させ、変更に強い設計にする。
(例)メモの作成機能
Interactor
Controller
④ 振り返り
今回のメモアプリ制作では、「単に動作するアプリ」を作るだけでなく、開発や保守が効率的かつ柔軟に行える設計を目指し、ドメイン駆動設計（DDD）を採用しました。
学んだこと
責務の分離による設計の明確化
1. ドメイン層において、ValueObjectを活用することで、データの不変性や型安全性を確保し、意図しないデータ変更を防げました。
2. ユースケース層（Interactor）にビジネスロジックを集中させることで、Controllerの責務がリクエスト処理に限定され、メンテナンス性が向上しました。
今後の課題
1. ドメインモデルの設計への理解不足
初めてDDDを本格的に採用したため、各層の役割の境界を定義する難しさを感じました。ビジネスルールをドメイン層に含めるべきか、ユースケース層に任せるべきかの判断が曖昧になり、一部の設計で一貫性が欠けてしまいました。
2. 過剰設計による効率低下
小規模なアプリにもかかわらず、EntityやInteractor, Repositoryなど細かく分けた結果、初期段階の開発効率が低下しました。単純なCRUD操作でも複数層を通過する構造になったことで、コードの複雑化を招きました。プロジェクトの規模や要件に応じた適切な設計レベルを見極める必要性を感じました。