『関数型ドメインモデリング』に関するメモ part1

2024-09-10 08:00:24

この記事は、Scott Wlaschinの著書『関数型ドメインモデリング』に関する個人的なメモです。 原著者の主張ではなく、筆者（猪股）の解釈と考察を含んでいます。

関数型アプローチと「ドメインモデル貧血症」

関数型プログラミングでは、データと振る舞いが分離されることがよくあります。 これは一見、Martin Fowlerが指摘する「ドメインモデル貧血症」のアンチパターンに似ています。 しかし、関数型アプローチでも適切に実装すれば、この問題を回避できます。

「ドメインモデル貧血症」とは

Fowlerは次のように述べています：

サービスの中に振る舞いを見つければ見つけるほど、ドメインモデルのメリットを奪っていくでしょう。 サービスの中にすべてのロジックを埋めてしまうと、何も見えなくなってしまいます。

この指摘は、抽象度の観点から理解できます。 ドメインレイヤーは最も抽象度が高く、それを呼び出すサービスレイヤー（アプリケーションレイヤー）はより具体的です。 「ドメインモデル貧血症」は、ドメインとして抽象化されたレイヤーにデータしかなく、 そのためにモデリングの利点が失われている状態を指します。

関数型アプローチでの解決策

関数型ドメインモデリングを適切に実践すれば、ドメインレイヤーには適切な抽象レベルで定義された関数が存在します。 これらの関数の特徴は：

1. 型：主な入力と出力がドメインオブジェクトである
2. 実装：
   • ドメインレイヤーにある別の関数をパイプラインのように合成することもあれば、
   • サービスレイヤーやインフラレイヤーなどの、具体的な関数を合成することもある

ただし、具体的な関数を合成するときは、以下のいずれかの方法で行われます：

• ドメインレイヤーの外部で行う
• ドメインの抽象レベルで定義された依存関係オブジェクト（例：リポジトリー）を受け取り、ドメインレイヤー内部で行う

この結果、ドメインレイヤーにはデータと振る舞いの両方が存在することになり、「貧血症」を回避できます。

結論

関数型アプローチでも、適切に実装すればドメインレイヤーにデータと振る舞いの両方を含めることができます。 これにより、オブジェクト指向設計で懸念される「ドメインモデル貧血症」を回避しつつ、 関数型プログラミングの利点を活かしたドメインモデリングが可能になります。