素敵なサムシングを独断と偏見で一方的に紹介するブログ(´・ω・`)

IT

【マイクロサービス】流行りのSpring Boot 2 + Gradle + Java8でマルチプロジェクトな個人開発をしていこう レイヤー構造化編【DDD(ドメイン駆動設計)】

投稿日: 2019年4月10日
最終更新日:

スポンサーリンク

336×280




土台は整ったのでAPIモジュールとして動かそう

手順

プロジェクトの構成

まずは各プロジェクトの構成を整理していきましょう。

今回は以下のような構造にしてみようと思います。

プロジェクト 説明
apiプロジェクト RESTfulなユーザーインターフェースを管理
servicemodelAPIやWEB、BATCH単位で異なるのでこの中にmodel/serviceパッケージを切っていきます
datasourceプロジェクト APIアクセスやDBアクセスなどを管理
entityプロジェクト DBテーブルなどのEntityを管理
valueプロジェクト 項目単位のValueオブジェクトを管理

果たしてこれが正解なのかは分かりませんが、一旦はこちらで進めてみようと思います。

考え方によっては、ServiceとModelも別プロジェクトにして参照する場合もありますが、API用のモデルやサービスWEBやBatchで使うことはなく、必要のない依存の結果無駄に容量が大きくなってしまうので、上記のようなプロジェクト構成にしています。

ただ、今回はレイヤー毎にプロジェクトを分けないだけで設計的にはMVC構造を考慮して行く想定でいます!

valueプロジェクト

まずは一番コアとなるvalueプロジェクトです。

このプロジェクトでは名前やメールアドレス、住所などの一項目レベルを管理していきます。

モデル毎にフィールドを用意するとバリデーションや記述がばらけてしまうため、一元管理がしにくくなってしまいます。

そこで、valueプロジェクトで管理することでそのサービスに登場する項目やバリデーションにブレがなくなるので、バグや仕様のねじれなども抑えることが出来るかな?と言う考えです。

entityプロジェクト

次はentityプロジェクトです。

こちらはデータ構造に対するentityモデルを管理するプロジェクトです。

例えば、DBのテーブルモデル等はAPIやWEB、Batchから見て必ず同一である必要があるため、このentityプロジェクトで管理して行く想定です。

datasourceプロジェクト

次はdatasourceプロジェクトです。

こちらは外部APIやDatabaseアクセスなどを行うクラスを管理するプロジェクトです。

こちらも同じく、外部APIやデータベースは、APIやWeb、バッチで共通なのでプロジェクトとして切り出しています。

apiプロジェクト

最後にapiプロジェクトです。

こちらはこれまでの手順で作ってありますが、この中にサブパッケージとして、controller/model/serviceパッケージを構築して行く想定です。

modelパッケージ

entityモデルと違い、I/Oモデルは必ずしもentityと一致するわけではないので、そのクッションをこのmodelで吸収して、共通のEntityモデルへと変換する想定です。

serviceパッケージ

こちらはAPI単位の業務処理を管理して行きます。

同じ会員登録でも、APIからの処理とバッチからの処理で業務内容が異なる可能性があるので、serviceも別プロジェクトにせずにAPIプロジェクトの一部として行きます。

controllerパッケージ

こちらは言わずもがなですが、RESTfulなAPIを構築するために必要不可欠なパッケージです。

infrastructureパッケージ

最後にinfrastructureパッケージです。

こちらはAPIモジュールに関する基盤周りの設定や共通定数等を管理していきます。

各プロジェクトの作成

では、実際に各プロジェクトを追加していきましょう。

ディレクトリ構成

ディレクトリ構成は以下のような形になりました。

各プロジェクトのビルド関連ファイル

次に、各プロジェクトのビルド関連ファイルの設定を見ていきましょう。
今回はdevtoolsプロジェクトのbuild.grdleは特に変更ないので割愛します

devtoolsプロジェクト

apiプロジェクト

datasourceプロジェクト

entityプロジェクト

valueプロジェクト

ポイント

ポイントは依存関係の優先度を考えて、dependencies句にてプロジェクトを参照する必要があります。
また、今回はlombokも使いたいので事前に依存関係に追加しています。

APIをそれぞれのレイヤーのクラスを使うように修正

では、プロジェクト構成が整ったところで前回作成したAPIを改修していきましょう。

今回の修正で以下のようになります。

valueプロジェクト

AccountIdValueクラス

AccountNameValueクラス

AgeValueクラス

SexValueクラス

entityプロジェクト

AccountTableEntityクラス

datasourceプロジェクト

AccountDataSourceクラス

apiプロジェクト

AccountListingElementModelクラス

AccountListingResponseModelクラス

AccountListingServiceクラス

RestPathConstクラス

AccountListingControllerクラス

動作確認

では、この状態でサーバーを起動して動作確認をしてみましょう。

正しく各レイヤーを通じてレスポンスが返ってくるようになりましたね♪

オススメの参考書

現場至上主義 Spring Boot2 徹底活用

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

終わりに

これで各レイヤーを通るベースとなる処理が整いました。

次回は実際にDBへアクセスする部分の準備としてFlywayの導入をしていこうと思います。

336×280




336×280




CATEGORIES & TAGS

IT, , , , , , , , ,

blogenist

Author: blogenist