今日も今日とて詩人業を行なっていきますよ!「ビジネスロジック」とは何か最近、業務で、比較的中長期的なアーキテクチャの見直しだったり、新機能の設計だったりをさせてもらう機会が増えた。コンポーネントをどういう風に分割するかとか、それぞれのコンポーネントを主にどのチームでメンテナンスしていくかとか、そういうのを考えるのは楽しい反面、かなり熟慮に熟慮を重ねないといけないものでもあるのでかなり責任を感じるというのもある。コミュニティだと思うけど)誰かに言われた「無限のメモリ空間と絶対に落ちないプロセスがあったとして、それでもそのコードを書かないといけないのならそれがあなたのドメインだ」という言葉だ。モデリングをしているとドメインロジックとかビジネスロジックとかって言葉はよく出てくるんだけど、これは結構なかなか人によって解釈が違っていたり、明確な定義がなくて難しい。本ではユビキタス言語というパターンがあって、それがちゃんと構築できてる前提であればドメインか非ドメインかわかりやすいんだけど、あれをちゃんと実践するのはすごく大変だ。僕も何年か前にあの本を読んで以来、チーム内でいろいろ試みてみたけどいまだに手応えのある成功体験はないし、プロダクトオーナーを含むチーム全体を巻き込んでいかないとかなり厳しい。判別したいことがあって、それをもとにその振る舞いをどこに実装していくべきかって考える感じのことがある。いうか、少なくともエンジニア同士では認識が揃っていて、何かを実装しないといけないときにそれをどこに定義すればいいかを迷わなくてもいい仕組みくらいだと思ってもらえるとよいと思う。それを修正しないといけないことになったとしたときに、それがビジネス都合なのか、アーキテクチャ都合なのかをちゃんと区別して、決してそれが混じらないということが実現されるだけでもかなりシステムのメンテナンスは楽になる。逆に、どっち側の変化によっても同じオブジェクトやメソッドが修正されるという状態は明らかにオブジェクト指向設計の単一責務原則に反しているし、障害が発生したときの問題切り分けが著しく難しくもなるので基本的に避けたい。やって分割されたオブジェクトやメソッドのうち、ビジネス都合で定義される側のクラスやメソッドがユビキタス言語になってるほうがなおよいけど、まあそこは一旦エンジニア同士で伝わればいいよねっていう妥協もアリだと最近は思い始めた。*1そして、その判別方法が「無限のメモリ空間」と「絶対に落ちないプロセス」を仮定することによる思考実験である。厳密には「断線・遅延しないネットワーク」も必要なのかもしれないけど、まあ要するに永続化やキャッシングから解放されたときにそれでもそのコードは必要なのかっていうことで、これはなかなか結構おもしろい思考実験である。僕たちがどれだけ永続化に関するコードを書いているかこれ、実際にやってみるとわかるんだけど、実際に考えてみるとほとんどのコードは必要なくなるってことに気づく。僕らが一体どれだけ永続化とキャッシュに振り回されてるのかってことだ。逆に言うと、そのレイヤーの心配ごとが軽減すれば僕たちはもっと自分たちのビジネスに集中できるし、ちゃんとしかるべきクラスだかオブジェクトだかに隠蔽してあげてビジネスロジック層からは意識しなくて済むようにしてあげるべきなんだよ。設計ってそういうことだと思うんだ。(おっと誰か来たようだシステムは何故バグるのかこれは完全に僕の経験則だけど、システム障害において、ビジネスロジックにバグが混入していたというケースは実はそんなに多くない。エンタープライジーな開発現場を経験してないので、そもそもこのレイヤーのロジックが薄いプロジェクトしか知らないというのはあるのかもしれないけど、それにしたって永続化やキャッシュに関するバグ、ミドルウェアや連携システムの冗長化不備がほとんどである。参照)の考慮漏れ永続化したデータの取得遅延まあ、平たく言うとスロークエリで、僕は勝手にこれを三大バグ発生要因と呼んでいる。ない、そんな理想郷がもしあるならその世界で実装されるシステムの障害は激減するはずだ。ビジネスロジックは意外と薄い(かもしれない)からこその創造性これは仮説だし、僕自身まったく検証できてないんだけど、それを念頭に読んで欲しい。思考実験として仮定した無限のメモリと落ちないプロセスは実際には実現不可能だけど、コンポーネント分割を工夫して永続化に関する関心事をあるレイヤーで隠蔽することはできるし、そうするべきでもある。それによって、少なくともビジネスロジック層から見れば永続化を意識しなくてよくなるので、先に述べた理想郷が仮想的には実現できる。このときに気づくんだけど、実際にはビジネスロジックなんて予想外に少ない。入ってるデータをそのまま画面に表示するだけだったりするし、あるとしたら表示整形くらいでそれはビジネスロジックというよりはプレゼンテーションのロジックだ。プレゼンテーションみたいなもんである。いう状況にエンジニアが放り込まれたらどうなる?エンジニアは本質的にコードを書きたい人種が多いんじゃないかと僕は思っている。そんな人たちが永続化の関心事が隠蔽されていて「コードを書く必要がない」環境に置かれたら、どうやったら自分たちはもっとコードが書けるか、こういう機能が実現できたらいいんじゃないかっていう創造性が発揮されるんじゃないかなと。これは予想というよりも自分と一緒に仕事をしてくれる人たちにそれを期待したいっていう意味も込もってるんだけど。会話しているかのような先輩エンジニアに尊敬の念をよく抱いたものである。ビジネスロジックが意外と薄いということは、逆に言えばシステムの根幹をなすのは永続化部分のコードだとも言えるのでそこに興味を持つのは自然なことだし、その場合は隠蔽された先の、永続化に関するコンポーネントの実装に携わればよい。重要なのは、今自分が何のコードを書いているのかちゃんと意識すること。ビジネスを加速していくために新しい機能を実装するか、その人たちを支えるために適切に永続化を隠蔽するか、趣味・嗜好も得手・不得手あるだろうし、会社やチームの都合でどっちがより重要なフェーズかってのもあると思うけど、少なくともそこが適切に分離されていて、どちらかをやっているときはもう一方を意識しなくていい状況は最低限実現していきたよねと思った週末なのであった。(いい感じにまとまった。16:01きょんさんからコメントいただいたので追記。このエントリで「ビジネスロジック」という言葉を使ったのは単にわかりやすいと思っただけなのと、代替できるわかりやすい他のワードが思いつかなかっただけである。今となっては反省している。あんなポエム書いていてなんですが、ビジネスロジックって何やねんっていう指摘はまあわかります。すべてのコードはビジネスに価値貢献してるはずだし、そうあるべきだし、すべてがビジネスロジックだろと言われればまあせやなって感じ。2016年9月24日エンタープライジーなシステムの名残なのかな、ビジネスロジックっていう用語って。きょんさんが言っている「適切に分割して、適切な注意を払え」っていうのがこのエントリで一番伝えたかったことで、それはどんなシステムでも必要なことだろうし、ましてオブジェクト指向のパラダイムを持つプログラミング言語を使っていれば息を吸って吐くようにできないといけないことではあるんだけど、実際にはそれができてない人やチームがあって、そのときにわりとわかりやすい分割の方法論としてのこの思考実験を提案したかったっていうのがたぶん正しい。このエントリで言っている「ビジネスロジック」というのは適切な命名が難しいので長ったらしい文章で説明するしかないけど「非機能要件を隠蔽して機能要件のみを抽出したもの」のことで、これは技術的バックグラウンドのない人のメンタルモデルに近いはずだし、ユースケースはここで抽出された語彙を使って記述されるべきだよねって僕は思っているので、そのためにはまずそこを分割して語彙を手に入れないといけないというのが主な主張。ちなみに「ユーザーストーリになればより非機能的な部分がふえてくる」というのはきょんさんのコメントで初めて気づいた。なんだガハハみたいな意見があったり、そういうデザインパターンや組織パターンがあるのだとするとそれはそれで興味深い気もする。システムというのは必ず何らかの要求にもとづいて構築されるもののはずで、従来(汎用機〜クライアント・サーバ時代まで?)はその要求の内容として機能的なものが支配的で非機能的なものはエンジニアが何とかすればよかったけど、今はそうじゃなくてむしろ非機能的な部分こそがビジネスの中心を担うことがある(実際、僕の今いる会社とかはその可能性がある)のだとすると、その非機能要求が一体どういう言葉で誰の手によって作られて、どういう伝達をされて、どのようにして実際のチームの開発プロセスに取り込まれていくべきなのかという議論は大変興味深い。なんとか品質モデルでいうと「当たり前品質」とかって呼ばれるものだったと思うんだけど、むしろこれが「動機付け品質」になりうるのだとすると、そのときの組織のあり方やアーキテクチャのあり方はどうあるべきなんだろうな〜とちょっと思ったりする。*1:DDD界隈の方々、すいません。マサカリは甘んじて受ける覚悟です。日目...2016-08-28知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ週末の午前中、カフェでアイスコーヒーを飲みながらふとポエム...2015-03-13ソフトウェアプロセスは人に依存するようになったこれを読んでなんとなく思ったことを書く。ソフトウェアプロセ...2015-01-01あけましておめでとうございますのポエム新年あけましておめでとうございます。見極め方Archiveスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。