無限のメモリ空間と絶対に落ちないプロセスを仮定して「ビジネスロジック」をあぶり出す

先日、前職の上司から「そろそろプロフィールに"詩人"を追加するべきだ」と言われました a-suenami です。今日も今日とて詩人業を行なっていきますよ！

「ビジネスロジック」とは何か

最近、業務で、比較的中長期的なアーキテクチャの見直しだったり、新機能の設計だったりをさせてもらう機会が増えた。

コンポーネントをどういう風に分割するかとか、それぞれのコンポーネントを主にどのチームでメンテナンスしていくかとか、そういうのを考えるのは楽しい反面、かなり熟慮に熟慮を重ねないといけないものでもあるのでかなり責任を感じるというのもある。

まあ、そんなこんなでいろいろうーんうーんって悩んでいると昔（たぶん DDD コミュニティだと思うけど）誰かに言われた「無限のメモリ空間と絶対に落ちないプロセスがあったとして、それでもそのコードを書かないといけないのならそれがあなたのドメインだ」という言葉だ。

モデリングをしているとドメインロジックとかビジネスロジックとかって言葉はよく出てくるんだけど、これは結構なかなか人によって解釈が違っていたり、明確な定義がなくて難しい。エリックエヴァンスの DDD 本ではユビキタス言語というパターンがあって、それがちゃんと構築できてる前提であればドメインか非ドメインかわかりやすいんだけど、あれをちゃんと実践するのはすごく大変だ。僕も何年か前にあの本を読んで以来、チーム内でいろいろ試みてみたけどいまだに手応えのある成功体験はないし、プロダクトオーナーを含むチーム全体を巻き込んでいかないとかなり厳しい。

で、もうちょっと簡単にそれがビジネスロジックなのか or not を判別したいことがあって、それをもとにその振る舞いをどこに実装していくべきかって考える感じのことがある。まあイメージとしては軽量 DDD というか、少なくともエンジニア同士では認識が揃っていて、何かを実装しないといけないときにそれをどこに定義すればいいかを迷わなくてもいい仕組みくらいだと思ってもらえるとよいと思う。もしそれを修正しないといけないことになったとしたときに、それがビジネス都合なのか、アーキテクチャ都合なのかをちゃんと区別して、決してそれが混じらないということが実現されるだけでもかなりシステムのメンテナンスは楽になる。逆に、どっち側の変化によっても同じオブジェクトやメソッドが修正されるという状態は明らかにオブジェクト指向設計の単一責務原則に反しているし、障害が発生したときの問題切り分けが著しく難しくもなるので基本的に避けたい。

もちろんそうやって分割されたオブジェクトやメソッドのうち、ビジネス都合で定義される側のクラスやメソッドがユビキタス言語になってるほうがなおよいけど、まあそこは一旦エンジニア同士で伝わればいいよねっていう妥協もアリだと最近は思い始めた。*1

そして、その判別方法が「無限のメモリ空間」と「絶対に落ちないプロセス」を仮定することによる思考実験である。たぶん厳密には「断線・遅延しないネットワーク」も必要なのかもしれないけど、まあ要するに永続化やキャッシングから解放されたときにそれでもそのコードは必要なのかっていうことで、これはなかなか結構おもしろい思考実験である。

僕たちがどれだけ永続化に関するコードを書いているか

これ、実際にやってみるとわかるんだけど、実際に考えてみるとほとんどのコードは必要なくなるってことに気づく。僕らが一体どれだけ永続化とキャッシュに振り回されてるのかってことだ。

逆に言うと、そのレイヤーの心配ごとが軽減すれば僕たちはもっと自分たちのビジネスに集中できるし、ちゃんとしかるべきクラスだかオブジェクトだかに隠蔽してあげてビジネスロジック層からは意識しなくて済むようにしてあげるべきなんだよ。設計ってそういうことだと思うんだ。僕が ActiveRecord を Dis るのは（おっと誰か来たようだ

システムは何故バグるのか

これは完全に僕の経験則だけど、システム障害において、ビジネスロジックにバグが混入していたというケースは実はそんなに多くない。エンタープライジーな開発現場を経験してないので、そもそもこのレイヤーのロジックが薄いプロジェクトしか知らないというのはあるのかもしれないけど、それにしたって永続化やキャッシュに関するバグ、ミドルウェアや連携システムの冗長化不備がほとんどである。

その中でも本当に多いのは

  • キャッシュに関する何か
    • リフレッシュされてなくて古いキャッシュを参照する、等
  • 失敗可能性（要するに NULL 参照）の考慮漏れ
  • 永続化したデータの取得遅延
    • まあ、平たく言うとスロークエリ

で、僕は勝手にこれを三大バグ発生要因と呼んでいる。（あくまで勝手に）

永続化もキャッシュもなくてよくて、NULL もない、そんな理想郷がもしあるならその世界で実装されるシステムの障害は激減するはずだ。

ビジネスロジックは意外と薄い（かもしれない）からこその創造性

これは仮説だし、僕自身まったく検証できてないんだけど、それを念頭に読んで欲しい。

思考実験として仮定した無限のメモリと落ちないプロセスは実際には実現不可能だけど、コンポーネント分割を工夫して永続化に関する関心事をあるレイヤーで隠蔽することはできるし、そうするべきでもある。それによって、少なくともビジネスロジック層から見れば永続化を意識しなくてよくなるので、先に述べた理想郷が仮想的には実現できる。

で、このときに気づくんだけど、実際にはビジネスロジックなんて予想外に少ない。もちろんドメインによると思うけど、Web アプリケーションにおける参照系の機能（つまり Web ページの閲覧）なんてだいたい DB に入ってるデータをそのまま画面に表示するだけだったりするし、あるとしたら表示整形くらいでそれはビジネスロジックというよりはプレゼンテーションのロジックだ。僕は今メディアの会社にいるのでなおさらだけど、ビジネス = プレゼンテーションみたいなもんである。

そういう状況にエンジニアが放り込まれたらどうなる？

エンジニアは本質的にコードを書きたい人種が多いんじゃないかと僕は思っている。そんな人たちが永続化の関心事が隠蔽されていて「コードを書く必要がない」環境に置かれたら、どうやったら自分たちはもっとコードが書けるか、こういう機能が実現できたらいいんじゃないかっていう創造性が発揮されるんじゃないかなと。これは予想というよりも自分と一緒に仕事をしてくれる人たちにそれを期待したいっていう意味も込もってるんだけど。

もちろん一定数のエンジニアには低レイヤーへの憧れみたいなものもあると思うし、僕も若い頃には Linux コマンドを使いこなして、呪文のようなバイナリを見たり、まるで MySQL と会話しているかのような先輩エンジニアに尊敬の念をよく抱いたものである。ビジネスロジックが意外と薄いということは、逆に言えばシステムの根幹をなすのは永続化部分のコードだとも言えるのでそこに興味を持つのは自然なことだし、その場合は隠蔽された先の、永続化に関するコンポーネントの実装に携わればよい。

重要なのは、今自分が何のコードを書いているのかちゃんと意識すること。

ビジネスを加速していくために新しい機能を実装するか、その人たちを支えるために適切に永続化を隠蔽するか、趣味・嗜好も得手・不得手あるだろうし、会社やチームの都合でどっちがより重要なフェーズかってのもあると思うけど、少なくともそこが適切に分離されていて、どちらかをやっているときはもう一方を意識しなくていい状況は最低限実現していきたよねと思った週末なのであった。（いい感じにまとまった。たぶん。）

追記 2016/09/25 16:01

きょんさんからコメントいただいたので追記。

このエントリで「ビジネスロジック」という言葉を使ったのは単にわかりやすいと思っただけなのと、代替できるわかりやすい他のワードが思いつかなかっただけである。今となっては反省している。

僕自身も普段の業務において「ビジネスロジック」という言葉はあまり使わないので、とりあえず Twitter ではしれっと弁明しておいた。

ただ何て言うんだろうな… まさにきょんさんが言っている「適切に分割して、適切な注意を払え」っていうのがこのエントリで一番伝えたかったことで、それはどんなシステムでも必要なことだろうし、ましてオブジェクト指向のパラダイムを持つプログラミング言語を使っていれば息を吸って吐くようにできないといけないことではあるんだけど、実際にはそれができてない人やチームがあって、そのときにわりとわかりやすい分割の方法論としてのこの思考実験を提案したかったっていうのがたぶん正しい。

このエントリで言っている「ビジネスロジック」というのは適切な命名が難しいので長ったらしい文章で説明するしかないけど「非機能要件を隠蔽して機能要件のみを抽出したもの」のことで、これは技術的バックグラウンドのない人のメンタルモデルに近いはずだし、ユースケースはここで抽出された語彙を使って記述されるべきだよねって僕は思っているので、そのためにはまずそこを分割して語彙を手に入れないといけないというのが主な主張。

ちなみに「ユーザーストーリになればより非機能的な部分がふえてくる」というのはきょんさんのコメントで初めて気づいた。確かにそうだ。

さらに追記 2016/09/25 16:16

もしかして機能的・非機能的という分類自体がもう必要なくて、やはり時代は ActiveRecord なんだガハハみたいな意見があったり、そういうデザインパターンや組織パターンがあるのだとするとそれはそれで興味深い気もする。

システムというのは必ず何らかの要求にもとづいて構築されるもののはずで、従来（汎用機〜クライアント・サーバ時代まで？）はその要求の内容として機能的なものが支配的で非機能的なものはエンジニアが何とかすればよかったけど、今はそうじゃなくてむしろ非機能的な部分こそがビジネスの中心を担うことがある（実際、僕の今いる会社とかはその可能性がある）のだとすると、その非機能要求が一体どういう言葉で誰の手によって作られて、どういう伝達をされて、どのようにして実際のチームの開発プロセスに取り込まれていくべきなのかという議論は大変興味深い。

十分な性能、十分なセキュリティ、安定稼働、こういったものは今までは UX のなんとか品質モデルでいうと「当たり前品質」とかって呼ばれるものだったと思うんだけど、むしろこれが「動機付け品質」になりうるのだとすると、そのときの組織のあり方やアーキテクチャのあり方はどうあるべきなんだろうな〜とちょっと思ったりする。

*1:DDD界隈の方々、すいません。マサカリは甘んじて受ける覚悟です。