背景
去年会社でドメイン駆動設計（DDD）の勉強会をしましたが、現在動いているサービスにすぐ活かすことが難しそうでした。（そして会社で使っているRailsの場合は適用しにくい部分もありました。）
この勉強会の後、クリーンアーキテクチャについても学びましたので、両方の考え方をあわせてゼロからアプリケーションを作った場合はどうなるかを考えてみました。
前提知識
DDDとクリーンアーキテクチャの詳細については以下に書いてある本などを読むといいですが、今回考えたアーキテクチャで特に意識したことを簡単にまとめます。
DDD
- ドメイン（アプリケーションの対象となる領域）の知識に焦点を当て設計をする
- ドメインに必要な知識と必要のない知識を考える
- ドメイン知識の関係を整理する
- ドメインのルールとアプリケーション（UIやユーザーが使う機能など）を分離する
詳細は ドメイン駆動設計入門 がオススメです。
クリーンアーキテクチャ
- UIやビジネスロジックの分離
- 同じアプリケーションを複数のデバイスで使えるようにするためにも必須
- 扱っているデータや主な機能が同じのため、処理を共通化したい
詳細は Clean Architecture がオススメです。
課題
今回考えたアプリケーションは、Music Player（音楽再生アプリケーション）です。
私は音楽が大好きで、自分のiTunesライブラリを徹底的に管理していますが、iTunesはアップデートがある度に苦しんでいます…
エンジニアなので気に入らなかったら自分で作ればいいじゃん、という決意に至りました。
実際にはまだ作っていませんが、こういうアーキテクチャにすればいいのではないかと考えています。
要件
まずは、どういう機能が欲しいかを考えました。
- ライブラリにある音楽を再生する
- 曲の関連情報（曲名、アルバム、アーティストなど）を管理する
- プレイリストを管理する
- 曲の細かい情報を関連する（ムード、作成者、タイアップ、国、言語など）
- 自動プレイリストを管理する
- 曲を検索する
- カバー曲を管理する
- アーティスト情報を管理する
- ライブ情報を管理する
- 歌詞を管理する
ドメイン
要件が決まると、それらを実現するためにどの知識が必要かを考えることで、ドメインが決まります。
上の要件を満たすために以下のドメインオブジェクトが必要だと考えました。
曲、アーティスト、アルバム、プレイリスト、ジャンル、ムード、作曲者（人物）、タイアップ、国、言語、PV、ライブ、活動エリア（場所）、歌詞、メディア、フォーマット、職能、ライブハウス
今回は自分の課題を解決するためのアプリケーションを作りますので必要の知識と必要のない知識を判断するのは楽でしたが、仕事で作っているプロダクトではここが一番大変でしょう…
そしてドメインオブジェクトの関係を表すとこちらになります。
矢印の向きは親から子になっていますので、「A→B」の場合はオブジェクトAはオブジェクトBの情報を持っている
E = エンティティ、V = 値オブジェクト
アーキテクチャ
私はまだPCで音楽を聴くことが多いですが、外出している時もスマホでも聴きますので、今回作るアプリケーションは最初からマルチデバイスを考えないといけません。そうなると、フロントエンドとバックエンドの分離はまず必要です。
次に考えたのはドメインの知識を持つモデルの使い方です。ビジネスロジックなどのドメイン知識がエンティティに入りますので、インターフェイスであるフロントエンドのためにこちらのロジックが一切入っていないDTOのようなものがあるといいです。バックエンドではモデル（エンティティ）を共通で使用し、フロントエンドではDTOを共通に使います。
最後に、裏で定期的に動かす処理について考えてみました。まだ具体的な機能は思い浮かんでいませんが、もし必要になった場合はバックエンドの共通モデルが使える状態にしておきます。
まとめておきますと、以下の図にようになります。
最後に
以上で全体のアーキテクチャになります。実際に作り始めると他の課題は出てくると思いますが、基本的にこんな感じに進めればいいかなと思います。
既存のアプリケーションでアーキテクチャを大きく変更するのは大変なのでそこまで色々考える機会は仕事で少ないですが、新規のアプリケーションに最近勉強した手法や考え方を活かすのを考えて面白かったです。