2019年12月18日のイベントで、ランチセッション枠として登壇しました。全体では700名を超える参加者で、私のランチセッション枠も満員御礼でした。ご参加いただいたみなさま、ありがとうございました！
springfest2019.springframework.jp
当日の発表内容を報告します。今回の対象は「社内業務システムの開発」です。また、タイトルは「ローコード開発」となっていますが、具体的にはWagbyに限定しています。そこはメーカーの発表として、お察しください。では、はじめます。
ドメイン駆動設計は自由度の高さが魅力だが...
もし私が30歳で、Wagbyをつくっていなければ、DDDは大好物なネタとして飛びついたでしょう。私からみたDDDの特徴は次のとおりです。
- 業務設計者（現場）がコードを書くのではなく、プログラマが業務を理解するアプローチ。
- 内製開発、アジャイルと相性がいい。
- オブジェクト指向が本来もっている能力を駆使して、現実世界をモデリングする。モデリング対象は業務データとその関連性、ロジックを含む。
- 実装されたコードは、設計情報の役割を兼ねる（のが理想）。
モデリングによってビジネス世界をコードで表現する... ちょっとした世界創造気分で、盛り上がります！
ところが実際にやってみた（とすると）おそらく次の点で詰まったことでしょう。
トランザクション処理
例えば、出庫伝票の作成時、倉庫の商品在庫を減じる、という業務要件です。いわゆるトランザクション処理で、RDB視点では、insertとupdateは一体となることが求められます。
出庫伝票 s = new 出庫伝票(); 商品 p = ...; … 出庫サービス.insert(s, p);
出庫サービスクラスにinsertメソッドを用意して、引数で商品を渡すのがよいでしょうか。あるいは、複数サービスを呼び出すメソッドを別に用意しますか。
@Transactional public void 出庫と在庫調整(出庫 s, 商品 p) { 出庫サービス.insert(s); 商品サービス.update(p); }
DDDは自由とはいえ、これらのアプローチには何らかの設計指針があった方がいいでしょう。このレベルで書き方が統一されていないとチームのメンバーは混乱しそうです。
モデル間の入力チェック
例えば、データ登録更新時、あるデータの存在チェックを行う業務要件です。
public class 売上伝票 { … public void set伝票No(伝票 dno) { if (請求伝票サービス.exists(dno)) { throw new BusinessLogicException("この伝票Noは利用できません。"); } this.dno = dno; } … }
売上伝票というモデルが、自身と異なる請求モデルの、しかもデータベースを操作する、ということが気になる... いや、サービスクラスを経由していることでRDBを隠蔽しているので気にしなくていいのか...
UI連携
例えば、ある項目の値が xx なら、この項目は入力可という業務要件です。
public class アンケート { … public void set自由意見(String 意見) { if (this.評価 == 評価.その他) { this.意見 = 意見; } else { throw new BusinessLogicException("評価がその他の場合のみ入力可。"); } } … }
ところが、実際にはこのような要件の実装はフロントエンド層（JavaScript）で行うのが一般的です。フロントエンド層が上のロジックを呼び出すというのも、遠回りな気がします。となるとクラスだけで完結しない、JavaとJavaScriptの両方をDDDで表現するにはどうすればいいのでしょう。
ドメインモデルだけですべての実装をカバーできない
つまるところ、今の実装技術は Java だけでなく、RDB 世界や UI 世界とも連携せざるをえませんが、きれいな分割ではなく、それぞれが侵食し合うことを許容しなければいけません。
Spring は DDDを支援するため、DB層やUI層との境界を用意し、異なる世界をつなげる役割を担うことができます。認証基盤や、パブリッククラウド運用支援といった非機能要件の一部も担うことができます。しかし、Spring がアーキテクチャ設計を代替することはありません。クラスごとの責任をどう捉えるか、をはじめとする設計方針は必要です。DDDは設計の自由度が高いことの裏返しで「これが正解」というものはないのですが、他社の設計事例は参考になることでしょう。ところが、です。
設計情報の公開は可能なのか
クラス設計の公開は、設計情報の公開とほぼ同義です。ERPパッケージのコアをさらすようなもので、利点だけでなく制約もしくは限界までも明らかになります。よって、完全な公開は難しいのではないでしょうか。
もちろん有償でのノウハウ提供という可能性はあります。再利用可能なクラス構造であれば、ブラックボックス化された ERP よりは、はるかに良いともいえます。ただ、これを購入する企業があるのかどうかは正直、わかりません。
現時点で考えるDDDの課題
これらの点を含め、私が感じている課題は次の3つです。
- オブジェクト指向に精通し、かつ、業務を理解しようとするエンジニアの獲得は難しい。
- 現場（発注側）と一体感を得られるという保証はない。エンジニアの評価をいかに高めるかという課題は残る。
- 自分たちの設計が妥当なのか？という疑問は常に残る。業界ごとのディープな情報交換の場を設けることができるか。
ローコード開発の世界
ここでいったん視点を切り替え、ローコード開発をみてみます。ローコード (LowCode) とは低レベルという意味ではなく、少ないコードで実装を進めると解釈してください。特徴は次の通りです。
- 業務設計者（現場）がツールの使い方を学び、ノンプログラミングまたはそれに近い形で実装を手掛けるというアプローチ。
- プログラマ は不要になるのではなく、ツールを補完する形でチームに参加する。高度な専門家という立ち位置だが、大量のプログラマは必要ない。
DDD開発との大きな違いは、誰が主体になるか、です。しかし実は私が Wagby でやりたいこと（そして DDD では実現が難しいと感じていること）があります。それは影響分析というテーマです。
影響分析と自動変更
上の図にあった「オブジェクト指向世界」「RDB世界」「UI世界」の、さらに一段上位の層に「設計情報」を用意します。もちろんDDDであっても、そのような設計情報は必要です*1。さて、その設計情報はどうやって書いていますか。もしかして Excel に、自由な日本語文章として記述していませんか？ その Excel 設計書と、ソースコードは完全に同期がとれることを保証できますか？
私が Wagby でやりたいことは、上流工程の設計情報（業務フロー図、スイムレーンなど）と、実際のソースコード（データ構造とアルゴリズムを実装したJavaコードだけではなく、RDB世界のテーブル定義や、UI世界のJavaScriptを含む）を同期させることです。
例えばスイムレーンで業務フローの一部を変更したとします。その変更がどのソースコードに影響を与えるのか、をその場で確認できる環境が欲しいです。また、業務項目名の変更を行うと、それがオブジェクト世界、RDB世界、UI世界すべてで影響している箇所を一気に書き換えたいのです。
DDD開発でも、IDEを使って、かなりのことができます。それでもExcel設計書との完全な同期は難しいでしょう。ということは Excel 設計書がなくなればいい？ はい、そのとおりです。Excel 設計書に変わる、完全にデジタルで、統一感があり、実装コードと密結合している設計情報こそが、私が求めているものです。
Wagbyのようなツールがあれば、現場、つまり非プログラマの方でも業務システムの開発ができます。私は先月の Wagby Developer Day 2019 で羽生さんが基調講演で放った「ビジネスプロセスプログラミング」というアイデアに惹かれています。これは現役のプログラマにとっても魅力的だと思います。
DDD とローコード開発の近未来
ここからはもう、独断です。DDDは業界ごとの、改変可能な業務クラス体系ができるのではないでしょうか。
Springのソースコード、拡張性が高い分、かなり階層が深いクラス体系ですよね。そういうイメージの「業務クラス群」です。
ではローコード開発はというと、実はここも似ています。業務クラスではなく、メタな設計情報の公開へと進むはずです。
さらにWagby限定ですが、Springベースの強みを活かして、DDDエンジニアが公開する業務クラス群との連携ができないか、と妄想しています。なかなか楽しいことになるのではないかと。
両者の発展レベルを 0,1,2,3 で整理してみました。似ています。
それもそのはずで、両者とも問題意識と、その解決のゴールが近いのです。それは「DXの実現」です。
まとめ - DX に至る道
これも先日の Wagby Developer Day 2019 で強調しましたが、デジタルトランスフォーメーション(DX)とは、"常に変更可能な基幹系の基盤をもつこと" です。それがゴールではなく、そのような環境を手にして、はじめて DX のスタートラインに立てるのです。経済産業省レポートの警告は、そもそも日本企業の多くは、このスタートラインにさえ立てないのではないかという危惧にあります。
DDD派は、エンジニア主体の内製チームで組織のデジタル化を実現しようとします。ローコード開発派は、現場主体の内製チームで同じことを狙います。
そして私は少なくとも、このような発想に至らず、硬直化したままの業務を RPA で効率化し、さらに硬直化を深めるというアプローチに邁進する企業文化に辟易しています。この「業務改善スピード重要性の無自覚さ」という病をどうすればいいのか、そもそも病の自覚さえないところが言う「RPAでDX」という日本語が理解できずにいます*2。
DDD派とローコード開発派は手段は違えど解決したい目標は同じ。さらに Wagby はローコード開発ですが Spring を基盤とする環境によって、DDD派と成果を共有できないか、そういう目線で開発しています、という話で締め括りました。
長文をお読みいただき、ありがとうございました。
