アドベントカレンダー専門テックブロガーのthorikiです。
私は長年Javaを使ったバックエンドサーバーの開発に、およそ20年くらい携わってきました。その中で、どうしても納得のいかない言葉があります。それは「ビジネスロジック」という表現です。
具体的には、アプリケーションのレイヤードアーキテクチャにおける「真ん中の層」、いわゆるサービス層やビジネスロジック層と呼ばれる部分を指します。この言葉が適切に機能や責務を表現しているか、常に疑問を感じてきました。
注意：アプリケーションの「3層アーキテクチャ」と「レイヤードアーキテクチャの3層構造」は全くの別物だということです。この2つを混同すると、設計や命名の議論が曖昧になりがちなので注意が必要です。
そもそもビジネスロジックとは？
まあとりあえずChatGPTに相談。
ビジネスロジック層とは、アプリケーションの設計において、ビジネスロジック（業務上のルールや処理）を担当する層のことです。
一般的に、アプリケーションの「中核的な処理」を扱う部分とされています。
例:
銀行システムでの「口座間の送金処理」
ECサイトでの「商品の在庫を確認し、購入手続きを進める処理」
業務上のルールや処理？アプリケーションの「中核的な処理」？
アプリケーションとしてのIFをコントロールするプレゼンテーション層や、DBなど外接サービスへのアクセスを担当するデータアクセス層に比べて、役割は曖昧です。
アーキテクチャの進化による呼び方の違い
アーキテクチャによっても昔、今で呼び方/役割が若干異なってきます。
MVC文脈（というか古典？2005年時点で一般化していたような・・・）
- プレゼンテーション層
- ビジネスロジック層
- データアクセス層
- もちろん異論はあると思う
- アプリケーション層
- ドメイン層
- インフラ層
- ドメインにあるエンティティが１レコードを指すとなっており、DBの要件がドメイン層に滲み出てしまっている感じがひと昔前という感じ
- ３層アーキテクチャにも出てくるアプリケーション層が中核処理をするところでなく、プレゼンテーション層と入れ替わっているのが余計わかりづらい。
DDD文脈
クリーンアーキテクチャだと３層ではなくなるが無理やり当てはめると
- コントローラー層
- ユースケース/ドメイン層
- アダプター層
となる。
ビジネスがドメインに変わっていますが、ドメインという言葉自体も曖昧です。
by ChatGPT
「ドメイン」とは、ソフトウェア開発における特定の業務や問題領域を指します。
業務領域や問題領域:
- ドメインとは、アプリケーションが解決しようとする「業務」や「問題」の領域全体を指します。
- 例:
- ECサイトの「在庫管理」「購入フロー」「支払い処理」など
- 銀行システムの「口座管理」「送金処理」「利息計算」
ドメインのルール:
- 各ドメインには固有の業務ルールやビジネスロジックが存在します。
- これらのルールをコードに落とし込むのがドメイン層の役割です。
イメージですが、このような感じに変わってきたということなんですかね？
とはいえ抽象的なことには変わりませんが・・・
ドメイン層内でのレイヤー
この図を眺めて思ったのですが、ドメインにネストされる形でビジネスロジックという層がありそうです。
ドメインをある程度具体化した場合、ドメインの複雑度によってレイヤーに違いも出るのではないでしょうか？
こんな感じ（クリーンアーキテクチャに寄せてますが）
ここまでレイヤーがハッキリしていると、何がやりたいかはつかめますね。
とはいえチームに説明する目的で、再度抽象化してしまうと、またよくわからないものに逆戻りしそうです。
ただ、抽象化の度合いによって層みたいなものはありそうです。
結論
ビジネスロジックを「層」として一括りに捉えるのではなく、まずはドメインごとに分割して考える方が理解しやすいかもしれません。
そして、それぞれのドメインに適したレイヤリングを検討することで、より明確な設計が可能になるはずです。
