DDD に基づいた実装を Clean Architecture を利用し再実装することで、DDD と Clean Architecture の比較とその実装方法を検討すること。
- Clean Architecture に準拠した設計
- 対象ドメインはペットストア
- Scala 2.11対応
- Play 2.3.x + Google Guice対応
- アプリケーションとしては REST like API
- ペットストア
- ベースとなる DDD の実装は、フォーク元の spetstore 。
Clean Architecture のレイヤー化アーキテクチャに従い、次のとおりのレイヤーに分割します。
- ドメイン層
- ユースケース層
- インターフェース層
- インフラ層
ドメインの目的は、ペットストアの運営です。 ペットやペットフード、アクセサリーなどを仕入れて、顧客に販売するためのドメインです(仕入れの概念が現在ないので実装です)。
- Customer Module = 顧客モジュール
- Customer (GE,A) = ペットストアの顧客
- StatusType (VO)
- CustomerProfile (VO)
- CustomerConfig (VO)
- Customer (GE,A) = ペットストアの顧客
- Item Module = 商品モジュール
- Purchase Module = 購買モジュール
GE = グローバルな識別子を持つエンティティ
VO = 値オブジェクト
A = 集約
とりあえず、重要なところだけSpecを書いています。
ここで重要なのは、モデルの表現(クラス名、属性名、振る舞いの名前(引数・戻り値も))にユビキタス言語以外の言葉を利用しないことです。
原則的に、これらの要素に、実装技術の言葉を含めてはいけません(実装技術の言葉を含めてしまうとメンタルモデルが離れていきドメインについて理解することが難しくなるため。ただし、StringやIntなどのデータ型や、ListやMap, Try, Option, Futureなどのコンテナ型は例外とする)。実装技術に関する知識は、アプリケーション層かインフラストラクチャ層に対応づけましょう。
- TODO
- 仕入れ先の導入
- 在庫の導入
- 商品モデルにサブ型を導入する
わかりやすくするために、特別なライブラリを用意せず、簡単な基盤コードを含めています。
- Entity = DDDにおけるエンティティの責務
- Repository = DDDにおけるリポジトリの責務
- RepositoryOnJDBC
JDBCに対応したリポジトリの骨格実装。ScalikeJDBCで実装。ちなみに、1エンティティが複数テーブルにマッピングされるような実装は今のところ作っていません。そのうち作ります。Specはこちら - RepositoryOnMemory メモリに対応したリポジトリの骨格実装。内部実装はMapですがRepositoryとして操作できる。Specはこちら
- RepositoryOnMemcached(TODO)
Memcachedに対応したリポジトリの骨格実装。 - CacheManagementRepository(TODO)
キャッシュのマネジメントを行うリポジトリ実装。
- RepositoryOnJDBC
- コントローラ(TODO)
- アプリケーションサービス(TODO)
- Play Framework 2.3.x
- Google Guice
- ScalikeJDBC 2.x
- json4s
- nscala-time
- specs2
- mockito