業務システムと抽象

杉本啓 @sugimoto_kei

昔、連結会計システムをオブジェクト指向で作ったことがある。あれはうまくいった。複雑な計算を組織化するのにオブジェクト指向は向いていると思う。超高速開発プラットフォーム的なものの上で作ったら、あれほどうまくいかなかったかもしれない。プラットフォームを選択するのは簡単ではない。

杉本啓 @sugimoto_kei

この連結会計パッケージでは、会計基準に依存しない部分と依存する部分を切り分けるために、前者を計算エンジンとしてオブジェクト指向で作り、後者はその計算エンジンが評価・実行する宣言的DSLとして作った。おかげで、会計基準変更への対応が容易になった。RT @sugimoto_kei

杉本啓 @sugimoto_kei

業務分野によるが、こうした、計算エンジン＋DSLという形式のアーキテクチャが合うケースはかなりあるように思う。ただし、自社開発のケースでは、そういった計算エンジンを組むのは引き合わない場合も多いだろう。パッケージだからこそ出来た面もある。RT @sugimoto_kei

杉本啓 @sugimoto_kei

ところで、僕は、オブジェクト指向の一番のメリットは、抽象化能力だと思う。この連結会計システムの場合、複雑で多様な計算を抽象化しその核心部分を計算エンジンとして抽出したわけだけれど、OOP言語でなかったなら、それは著しく困難だったと思う。... RT @sugimoto_kei

杉本啓 @sugimoto_kei

そう考えると、OOP を使いながら抽象化を否定するというのは、OOP の一番オイシイ所を捨てているようにしか思えないのだけれど、どうなのだろう。RT @sugimoto_kei

杉本啓 @sugimoto_kei

世間では、そういう抽象化が必要なのはインフラコードであってアーキテクチャチームが書く、業務システムチームはベタなコードを書く、という暗黙の了解があるように思うけれど、業務の論理の中にこそ、抽象化によって価値をもたらす機会が潜んでいるのではなかろうか。@sugimoto_kei

杉本啓 @sugimoto_kei

ついでにいうと、業務システムはエンティティと値とリポジトリとファクトリとイベントだけで出来るものじゃないよね。これらを強調し過ぎているのは、DDD本のイケてないところだと思う。この連結計算エンジンは業務の本質をよく表していたが、これらのいずれでもない。@sugimoto_kei

杉本啓 @sugimoto_kei

一方、業務システムに抽象化を適用するには、その業務領域で普遍なことと変わり易いことを切り分ける力、あるいは、その業務に働く変化要因（法制度か組織のニーズかなど）を切り分ける力ことが必要。そのために、設計者には、自分なりの「業務観」が要求されると思う。@sugimoto_kei