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