OOじゃないDDDについて

概要

モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。

端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。

DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ

Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。

エンティティ、バリューオブジェクト、アグリゲート、リポジトリなどのようにEricが紹介したDDDにおける実装方法は少なくともクラスベースOOを前提とした何かだと考えられます。

データフロー図で表現できるようなアプリケーションは関数型の考え方が似合う

UNIXコマンドラインツール、PowerShell、関数型プログラミングの一部の機能、に見られるようなパイプ&フィルターパターンというのは、データフロー図で表現できるようなアプリケーションにおけるモデリングとバッチリあいます。

例えば、あるデータが入力されたら、延々とそのデータに対して変更を加えていったり、絞り込んだり、集計したりするアプリケーションです。

ひどい例かもしれませんが、「様々な人にレビューしてもらったり、判子をもらうことで、最終的に許可をもらう成果物」といったものはまさしくそうですよね。 次のような手順とかですかね。

1. 開発者がコミットした設計書
2. チーム内レビュー合格判子をもらった設計書
3. Aさんレビュー合格判子をもらった設計書
4. Bさんレビュー合格判子をもらった設計書
5. 承認会合格判子をもらった設計書
6. リリース判子をもらった設計書

このようなシンプルなデータフローとして表現できる場合にはこれがドメインモデルだと言っていいと僕は思っていて、これをDDDとして実装するなら、「よりパイプ&フィルターパターンを実装しやすい設計方法」を取るほうが楽かと思います。

実際にはもっとたくさんの条件があったり、他の作用があったりするので、それらにどう対処するかでやはりOO的にやっていくのか、モナドで何かくるんでうまいことパイプ的に見せるのかということはありそうですが、このような手順で見れるなら簡単な場合というのもあるのは確かです。

まぁ、わかっている人からしたら「それはVOとなんたらとなんたらを組み合わせたやつだよね」とか言いそうなんですけど、 僕からしたら「なら、それに名前つけたり、こういったパターンがあるって誰かに伝えたり、議論しあったほうがいいと思うよ」的な。なので、こうやって書いたわけですが。

他に考えられる例

さっきは残念な例でしたが、例えばそれぞれの一部ですが次のような例もあると考えています。

• 証券の扱い
• CIツールのようなジョブシステム
• ビルドツール

まぁ、なんらかの形でなんたらフローみたいなのに表現できて、入力にだけ着目するようなものやりやすい的な感じでしょうか。（つまり、副作用が少なめということなんだけど）

ついでに言いたかったこと

こういったことがシンタックスとして見えやすくなる可能性を秘めているF# のパイプライン演算子は素晴らしいし、みんなもF# をやろう！！！！

F#で関数型言語に触れてみよう from wof moriguchi

実践ドメイン駆動設計 (Object Oriented Selection)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践 F# 関数型プログラミング入門

関数プログラミング実践入門 ──簡潔で、正しいコードを書くために (WEB+DB PRESS plus)