ビジネスロジック、ドメインロジックとは？

ビジネスロジックは分けてください。
ビジネス・ドメインロジックは他のレイヤに依存してはいけません。

システム開発に携わったことある方は、このような言葉をよく聞くと思います。

何となく意味は通じると思います。UIを改善するコードはビジネスロジックではないことも何となく理解できると思います。

しかし、特定の条件のデータをDBから取り出すとか、ユーザーが検索したデータが実際にあるかどうかを確認するコードはとか、システム開発する時には様々なロジックを考えなければなりません。

以外と質問されることも多く、一度整理しておこうと思います。

ドメイン、ビジネスの意味

ドメインロジック、ビジネスロジックという言葉は同じ意味だと思ってよいです。
「ドメイン」という言葉と「ビジネス」という言葉は違う意味ですが、なぜロジックを付けると同じ意味になるんでしょうか。

IT業界でドメイン、ビジネスという言葉は、「解決したい現実世界の問題」を指しているからです。

例えば、銀行アプリでは金融サービスや銀行の業務がドメインです。銀行アプリが解決しようとする問題が金融業務をスマホやパソコンでできるようにしてくれます。

TikTokやインスタのようなSNSアプリなら動画の撮影、鑑賞、他人への共有とフィードバックがドメインです。

その一方で技術的な問題にあたるものは「ドメイン」とは区別されます。

銀行ユーザーのデータをどうやって効率的かつ安全に保存するか。動画データをどうやって早く読み込んでデバイスに表示するか。などがそれにあたります。

ですから、「ドメインロジック」とか「ビジネスロジック」と言うときは、その「現実世界の問題」を解決するコードを意味します。ドメインに対する解決策やソリューションともいえます。

そもそもシステムは現実問題を解決するものじゃないですか？という疑問があるかもしれません。

しかし、実際にシステム開発する際には、問題を解決するコードだけではなく、多くのコードを開発しなければなりません。問題を解決するコードが実行できるようにするコードや、インプットとアウトプットを処理するためのロジックです。

例えば、データベースに接続したり、サーバーと通信し、ユーザーの動きに反応するコードが必要です。

これらはドメインロジックと区別し、アプリケーションサービスロジックと呼ばれます。

ドメインロジックとアプリケーションサービスロジックを区別する基準は、「ビジネス的な意思決定」です。

このコードは現実の問題、つまりビジネス対する意思決定をしているか？

ドメインロジックは現実問題に対する意思決定をするコードです。

残りのコードは、その意志決定のための入力値を作成するか、その決定の結果を解釈して表示し、伝えるコードです。

たとえば、一般的なモバイル送金アプリで考えてみましょう。

送金機能を行うコードがあります。このコードの詳細機能は次のような機能から構成されています。

上記コードをビジネスロジックとサービスロジックに区別するならどうでしょうか。

ビジネスロジックは以下の詳細機能です。こちらの詳細機能たちは送金に対する意思決定をしています。

その一方で、サービスロジックににあたる詳細機能は次の通りです。

このサービスロジックはビジネスロジックが意思決定できるように、入力を制御し、外部サービス/DB/UIに出力値を連携します。

ある詳細機能のコードがビジネスロジックなのか、サービスロジックなのか、曖昧な場合は二つが混ざっている可能性があります。

その場合はロジックを分けるように改修したほが良いでしょう。

例えば、外資口座のドルを円で換算して残高を表示する関数があるとしましょう。

この関数だけだと、ビジネスロジックなのかサービスロジックかあいまいですが、

「ドル円の為替レートを決定するロジック」と「残高を表示するロジック」で分けると前者がビジネスロジックで、後者がサービスロジックであることが分かります。

このような基準でビジネスロジックとそうではないロジックを分ける理由は、明確な関心の分離のためです。関心の分離とは、ソフトウェア工学用語で、変更に強いソフトウェアを設計するための考え方です。

ビジネスロジックとサービスロジックはどんなシステムでも役割が区別されており、変更の理由も異なるからです。

ビジネスロジックとサービスロジックを切り分けて結合度を下げると、開発者がロジックを理解しやすくなります。

また、DBやUIなどの技術的なスタックを気にせず、ビジネスロジックを理解することができます。そして、ビジネスポリシーが変わった際に、変更、機能追加が簡単になり、市場の変化によってシステムをタイムリーに提供することが可能です。

このような理由で、クリーンアーキテクチャでは、ビジネスロジックをシステムの中核において、他のレイヤに依存しないように設計します。他のレイヤはビジネスロジックとやり取りし、外部に伝達するように明確に分離します。