ソストウェア設計の話の中で、ビジネスロジックというのは、ビジネスロジック以外の部分を省いたものであるというような言われ方をすることがあります。(ビジネスロジックという言葉が差す物が曖昧であることへの皮肉という面があると思います)

以前にビジネスロジックについて考察した記事を書いています。

• ビジネスロジックとは何か？
• ドメインを純粋に保つ (レガシープロジェクトの改善活動について) (1)

これらの記事の中で、自分なりのビジネスロジックというものに関する学びを整理しているのですが、ソースコードの中でビジネスロジックを上手に纏める方法という意味では、現在も学習している最中であるし、まだまだ十分上手に説明しきれていないと感じています。上記の記事を書いていた時より考えが整理された部分もありますので、改めてビジネスロジックとソースコード上の表現について自分の言葉で説明する記事を書いてみたいと思います。この記事を読んだ方のビジネスロジックという言葉の解像度が上がったり、今までとは異なる視点を持ってもらえたら嬉しいです。

ビジネスロジックとは？

先述の過去の記事で、ビジネスロジックを自分の言葉で定義しています。

ビジネスロジックとは、業務の専門家が認識している知識である
ビジネスロジックとは何か？

システムを開発したり改善したりする目的は、極度に単純化すると、業務の専門家が認識している問題を解決することです。ソフトウェアエンジニアは、直接的か間接的かに依らず業務の専門家から情報を得て、問題を解決することを目指してシステムを開発します。ビジネスロジックと呼ばれるものは、業務の専門家から得た知識をソフトウェアエンジニアが解釈してシステムの仕様として定義したものと言えます。

ビジネスロジックは「知識」であるということは、誰の知識であるかによって分類することが可能です。ひとつのシステムでも、営業業務の専門家から出てきた要件と、在庫管理業務の専門家から出てきた要件の両方を満たす必要があるという状況はよくあります。このような場合、ソースコード上でも営業業務の専門家の知識と在庫管理業務の専門家の知識は、文脈が異なるので混ぜてはいけないはずです。

ビジネスロジックの最小構成要素としてのビジネス概念

ビジネス概念
ビジネス上に現れる業務的な概念
ドメインを純粋に保つ (レガシープロジェクトの改善活動について) (1)

以前の記事の中で、既存のソースコードの中からビジネスロジックを把握する際に、ビジネス概念(こちらも造語)を探すことに注目しました。

業務の専門家が「何をどのように認識しているか」に着目して、ビジネス概念を特定します。物だけでなく、方針やルールや計算処理や判定処理もビジネス概念の候補となります。

ビジネスロジックのソースコードでの表現

業務の専門家の知識の中から、抽出したビジネス概念をなるべく自然な形でディレクトリ構成のソースコードとして表せることが理想的な状態と考えます。簡易的ではありますが、ビジネス概念の例を上げてみます。

• 営業業務の専門家の知識
  • 顧客ランク ・・・ 顧客ランクに基づく営業施策や、割引ロジックの適用
  • 商談ステータス ・・・ 各ステータスごとに営業のフォローアップ内容や次のアクションが変わる
  • 販売キャンペーン ・・・ 特定期間に実施する販売促進施策
• 在庫管理業務の専門家の知識
  • 在庫補充ポイント ・・・ 在庫量が一定の閾値を下回ったときに補充を行うためのポイント
  • 賞味期限管理 ・・・ 在庫処分や消費期限間近の商品に対する処理
  • 保管ロケーション ・・・ 保管場所の管理により、在庫の正確な位置やピッキングの効率化を図る

抽出したビジネス概念は、プログラミング言語の基本的な要素で表現できることが望ましいです。一般的には、それぞれのビジネス概念をクラスや列挙型で表現するのが良いと思います。

以下は、抽出したビジネス概念をクラス図にマッピングしてみたひとつの例です。

ビジネスロジックは、いわゆるドメインレイヤー(○○アーキテクチャーのド真ん中)に実装することになりますが、上の図のようにイメージを作ることができれば、ディレクトリ構成も含めてソースコードで見通しが良い状態で表現することができます。

まとめ

営業業務の専門家の知識と在庫管理業務の専門家の知識は、文脈が異なるので混ぜてはいけない

この一文が主張している事は、SOLIDの単一責任原則(SRP)と同じことであり、ドメイン駆動設計(DDD)の区切られた文脈と同じことだったという事に、今気が付きました。

SRPの主張は、以下のページの説明がわかり易いです。

モジュールはたったひとつのアクターに対して責務を負うべきである。 単一責任の原則（Single responsibility principle）について、もう一度考える

本記事の文脈では、「単一のビジネス概念はたった1種類の業務の専門家の知識を体現するべきである」とも言い換えることができます。前述のビジネス概念をクラス図にマッピングした図は、業務の専門家の知識ごとに1階層目でグルーピングされているため、別のアクター(業務の専門家)の要求が混じににくい構成になっていると言えます。

区切られた文脈については、業務の専門家の知識ごとにディレクトリが異なる構成になるので、自然に文脈が区切られる力学が働きます。区切られた文脈はシステム全体を分割するマイクロサービス化の話とセットで語られることが多いですが、むしろビジネスロジック内で文脈を区切るという事の方が本質的なのではないかと思いました。

ビジネスロジックをソースコードの中でどのように表現することができるのかを、主に概念的な説明を中心に書いてみました。フィードバックいただけると嬉しいです。