Clean Architecture・DDDをもとにしたFlutterアプリのモジュール分割＆命名法

DDDの戦術的設計とは、DDD（ドメイン駆動設計）という設計手法における具体的な実装の方法論を指します。

これは、レイヤー分けの方法論で、例えば以下のようになります。

• アプリケーション固有のロジック: XXX、XXXService
• 永続化（DBなど）に関するコード: Repository
• アプリケーション固有のロジックを組み立てる役目: ApplicationService、UseCase
• UI

(アプリケーション固有のロジックに関しては、Entity、ValueObjectというパターンを使うことでXXXクラスを作るという形になります)

これらは、アプリケーション全体の構成を把握するために便利でもあります。この記事では、上記をさらに拡張して、以下のようにしてみます。タイトルは「Flutterアプリの」としましたが、Flutterアプリ以外でも同じようなものかと思います。

• ドメイン（ある分野特有の）ロジック: XXX、XXXService
• webAPIとの通信を行う: Api、ApiClient、DAO(Data Access Object)
• UIとUseCaseへの橋渡し役: Controller、Notifier、BLoC
• 永続化（DBなど）に関するコード: Repository
• ドメインロジックを組み合わせて一連の流れを作る役目: ApplicationService、UseCase
• UI: View、Widget、Page、Dialogなど
• DI: Provider

これに似たクリーンアーキテクチャでも、以下のような図が出てきます。

クリーンアーキテクチャ図

さて、一般的な言葉だけでは分かりづらいと思いますので、実際の例を示します。Flutterの人ならよく見たことのあるCartアプリを例にします。以下のような設定です。

• ドメインロジック: Item、Cart、CartService
• 複数のクラスを組み合わせたロジック: Facade
• webAPIとの通信を行う: ItemAPI、CartAPIClient
• UIとUseCaseへの橋渡し役: CartController、CartNotifier、CartBLoC
• 永続化（DBなど）に関するコード: CartRepository、ItemRepository
• ドメインロジックを組み合わせて一連の流れを作る役目: CartApplicationService、ItemUseCase
• UI: CartView、CartPage、AddToCartDialog
• DI: CartProvider

NotifierやProviderという言葉は、Flutter開発者ならよく目にしますよね。

これを図にすると、以下のようになります。

この時点で、これらを組み合わせてアプリを作っていくことが、なんとなくイメージできるのではないでしょうか？この記事の読者の皆様のモジュール分割、命名の際の参考になれば嬉しいです。

次回「実装編」に続くかもしれません。