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

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

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

YouTubeも見てね♪

Anker PowerCor

created by Rinker
Anker
¥4,990 (2024/03/15 15:06:44時点 Amazon調べ-詳細)

旅行には必須の大容量モバイルバッテリー!

レッドブル エナジードリンク 250ml×24本

created by Rinker
Red Bull(レッドブル)
¥4,080 (2024/03/15 19:03:47時点 Amazon調べ-詳細)

翼を授けよう!

モンスターエナジー 355ml×24本 [エナジードリンク]

created by Rinker
モンスター
¥4,748 (2024/03/15 19:03:48時点 Amazon調べ-詳細)

脳を活性化させるにはこれ!

ドラゴンクエスト メタリックモンスターズギャラリー メタルキング

created by Rinker
スクウェア・エニックス(SQUARE ENIX)
¥3,250 (2024/03/15 19:03:48時点 Amazon調べ-詳細)

みんな大好き経験値の塊をデスクに常備しておこう!

BANDAI SPIRITS ULTIMAGEAR 遊戯王 千年パズル 1/1スケール

created by Rinker
BANDAI SPIRITS(バンダイ スピリッツ)
¥7,180 (2024/03/15 15:06:46時点 Amazon調べ-詳細)

もう一人の僕を呼び覚ませ!!

MOFT X 【新型 ミニマム版】 iPhone対応 スマホスタンド

created by Rinker
MOFT
¥2,880 (2024/03/15 19:06:03時点 Amazon調べ-詳細)

Amazon一番人気のスマホスタンド!カード類も収納出来てかさ張らないのでオススメです!

サンディスク microSD 128GB

スマホからSwitchまで使える大容量MicroSDカード!

土台は整ったので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クラス

動作確認

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

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

終わりに

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

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

CATEGORIES & TAGS

IT