はじめに
MVCなど従来の多層アーキテクチャを採用したアプリケーションにおいて最初にどこから実装を始めるでしょうか。
おそらく多くの開発者は最初にデータベースの構造をどのようにするかを決めて、そのあとにビジネスロジックを実装したはずです。
私もデータベースのテーブル設計をどうするかから実装を始めていました。
多くのチュートリアル系の記事でもまずはデータベースの構築から始めることが多いはずです。なぜならデータベースがないと保存や参照が行えないからです。依存の流れに沿っている訳です。
このような流れで開発することはまったく理に適っておらず、適切な開発を行うのであれば、何よりも先にビジネスロジックから実装すべきです。
補足: ビジネスロジックとは
ビジネスロジックは業務に関する処理のことを指します。
例えば、MVCで言うとビューのように表示に関するものやモデルのようにデータベースを操作したりといった業務とは直接関係ないもの以外です。
データベースを中心に設計してしまう原因
O/Rマッパー(Object-Relational Mapper)をビジネスロジックで利用すると問題が起こります。
例でいうとLaravelフレームワークにおけるEloquent ORMは、
ドメイン駆動設計(Domain-Driven Design)におけるエンティティとリポジトリの2つの役割を兼ねています。
ドメイン駆動設計のエンティティとクリーンアーキテクチャのエンティティ
https://nrslib.com/clean-ddd-entity
データベースを中心に設計することによる問題
DDDにおけるドメイン層に配置されるべきエンティティが永続化層(リポジトリ)に配置されてしまいます。
ドメイン層と永続化層が密結合となり、ドメイン層のコードがビジネスロジックに加えて、永続化の関心事である即時読み込み(Eager Loading)や遅延読み込み(Lazy Loading)、キャッシュの読み書き、データベーストランザクションの管理なども扱う必要が出てきてしまいます。
こうなるとアプリケーションは柔軟性が損なわれてしまいます。
補足: レイヤー構造
1. ドメイン層 (Domain Layer)
- ビジネスロジックやビジネスルールを実装する層
- ドメインモデルを置く
- エンティティ（Entity）
- 値オブジェクト（Value Object）
- ドメインサービス（Domain Service）
2. アプリケーション層 (Application Layer)
- アプリケーション固有の処理の流れやユースケースを実現するための層
- ドメイン層とインターフェース層の橋渡し役
3. インフラストラクチャ層 (Infrastructure Layer)
- データベースや外部APIなど、外部との接続を担う層
- 意図が伝わりやすいので永続化層と呼んでいます
4. ユーザーインターフェース層 / プレゼンテーション層 (User Interface / Presentation Layer)
- ユーザーとのやりとりや、外部システムへの出力を担当する層
どうやって解決するか
本記事は「手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発」の「2.1 データベース中心の設計になってしまう問題」から抜粋して紹介させていただきました。
この本にはパッケージ構成やコード例など細かく実装する上で困る問題事についても書かれてありました。もし興味をもった方はぜひ読んでみてください。
PR
私が所属するミライトデザインではYouTubeで動画やライブ配信、connpassで月1の勉強会(オフライン&オンライン)を開催しています。
もし興味があれば、チャンネル登録や勉強会へ遊びに来てください🤗