Builderscon Tokyo 2019 で「ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ」というタイトルで登壇してきました #builderscon

タイトルの通り、登壇してきました。

イベントページはこちらです。

builderscon.io

今回僕はスタッフとしても関わらせていただいたのですが、そちらのレポートは別の記事にしようかと思っており、とりあえず登壇内容に関する話だけしようと思います。

発表資料

資料はこちらです。

2019/09/04 13:26 追記

かとじゅんさんから指摘をもらったのでメモしておきます。

確かにスマート UI のほうが直感的かもしれませんね。

事前練習（素振り）

事前の練習を何度かしたのですが、正直、納得のいく水準でなかなか喋れず、練習相手になっていただいたみなさんにはグダグダなトークをお見せしてしまい申し訳ありませんという気持ちが強いです。

DB やプログラミング言語の機能などの実装技術に対してできるだけ中立な、つまり特定の実装技術の紹介にならないように心がけた結果、逆に抽象的すぎる内容になってしまったのかなと自己分析しています。

ただ、結果として、三部構成の最後に位置付けた具体的実装の部分（バリデーション、整合性、採番、状態管理、キャッシュ等）はそれなりにはうまく伝えたいことを伝えることができたかなと思っています *1。

そんなこともあって、とにかく素振りは大事だなと思いました。

前日

僕の発表は 1 日目だったので前日には前夜祭が開催れており、その後、各位が北千住で飲んでいるのは Twitter 等から情報としては得ていたのですが、そういう心理状態でもなかったのでこの日は飲まずにさっそうと帰りました。そして、直前にもかかわらずスライドをいじり続けるという…

みなさん、もっと準備はしっかりやりましょうね（自戒）。

発表当日

冒頭にも書いた通り、今回の builderscon では僕はスタッフもやっていたのですが、当日は午前中の会場設営だけやり、午後はずっとイメージトレーニングしたりしてました。

偶然ではあったのですが僕がうろうろしているとその前の枠ですでに発表を終えたそーだいさんとたまたま遭遇して、いろいろ雑談したりして緊張がほぐれたという隠れたいい話もあります。

まあ、そんな感じで、偶然も重なって何とかお話させてもらうことができたのですが、蓋を開けてみれば大変多くの人にご来場いただき、大入り賞までいただくことができました*2。来ていただいたみなさん、本当にありがとうござました！

伝えたかったこと、伝えれなかったかもしれなかったこと

発表の中でも言及しましたが、今回の発表のきっかけとなったのは吉祥寺.pmで話した以下の発表です。

a-suenami.hatenablog.com

これを発表したあと、周囲から「SoEの場合は〜で、SoRの場合は〜」とかって言われることが増えましたし、実際の仕事ではエンジニアじゃない人たちからもこれらについて言及されるようになってしまい、「あれ？これバズワード化するパターンなのでは？？」みたいになったので、もっとちゃんと言語化するべきだと思ったし、何を目的とするかをあらためてちゃんと伝えたほうがいいなと思ったのがきっかけです。

今回はアクターというものに着目しましたが、すごく雑に一言でいうと「誰のために設計してるのかちゃんと考えましょうね」ってだけの話で、それ自体も今のところ僕がそう思ってるというだけの話*3なので異論、反論大歓迎ですし、この発表をきっかけにこれについての議論が盛り上がってくれれば僕としてもこれほど嬉しいことはありません。

三部構成の最後、具体的な実装の話は僕にとっては正直おまけだったのですが、技術系のカンファレンスでみなさんが聞きたいと思うのは実際には具体的な実装の話だろうし、前述した通り素振りの段階でそれについてはフィードバックがあったのでがんばっていろいろ厚みをつけてみたという感じです。ここに関しては今後いろいろなドメインに関わることで僕自身の中でアップデートがあると思っているので、それについては都度共有させてください。

嬉しかったこと

今回の登壇を聞いていただいた方からいろいろ嬉しい評価はいただいたのですが、その中でも一番嬉しかったのが「今まで DDD 本の存在は知っていたけど読めてなかった。今回の話を聞いて読むべきだと思いました。」って言われたことです。今回は基本的にはエヴァンスの主張をそのまま引用しただけの部分が多かったのですが、それでも少しずつ僕の言葉で DDD というものを伝えることができるようになってきたのかなと感じています。

おまけ

発表後に興味深い質問をいただいたので 2 つ紹介させてください。

SoR の持つ情報のうち、ある SoE にはフルに見せてもよいが、別の SoE には一部しか見せたくない場合、どうするのがよいか

これについて、僕は会場で「SoRを分割するか、モデルやシステムごと分割しないまでもエンドポイントを別にする」と回答しました。たとえば「顧客」というエンティティがあったときに、IDと名前だけしか知ってはならない SoE と住所や連絡先情報まで含めたすべての情報を知ってよい SoE があるのであれば、それらは別の集約と考えられるからです。ID は同じですが。

ただ、その後詳しくをお話を聞くともう少し複雑っぽくて、SoE が無数にあり、それぞれが必要とする情報構造がかなり違う（つまり、エンティティの形が数パターンに定まらず無数にある）というケースのようです。実際にそのようなことで悩んでいるともおっしゃっていました。実装技術でいえば GraphQL が向いている要件といえば伝わるでしょうか？そういう感じです。

これについて、僕は以下の興味深い問いに落ち着くかなと思いました。

認可とはドメイン知識か、それともプレゼンテーション要件か。それを決定するアクターは誰か。

SoR / SoE 間の通信は一般にバックチャンネル、要するにユーザからは見えない通信経路のため、あるアクターに見せてはいけない情報があるのであればそれを担当する SoE がフィルタリングすれば済むだけの話です。SoR はすべての SoE にフルに渡してよいのです。それがそうではないということは認可そのものが重要なドメイン知識である可能性があるのではないかと感じました。

ちなみに同様の話をアフターパーティでも別の人としたので、これについては僕も自分の業務で似たような場面に遭遇したらしっかりと考えてみたいと思います。

2019/09/03 14:51 追記

質問者ご本人からリプライをもらったのでご紹介します。

情報セキュリティ管理基準というドメインを別途想定し、それを SoE の前段に置くという設計でやられているそうです。確かにこれなら意思決定者たるアクターも分離されそうですし、よさそうですね。

SoR が UI を提供することはあるのか

世の中には naked objects パターンなんていうものもあるのですが、これについては僕は「ない」と答えました。これについてははっきり言い切ることは若干の迷いもあったのですが、もう少し掘り下げて言及したいと思います。

  • UI というのはそのアクターにとってのシステム利用目的をかなり強く反映（あるいは逆に束縛）する
  • ドメインモデル（=SoR のモデル）は SoR / SoE というシステム分割の観点から見ると、複数のアクターの仲裁者という側面があり、どうしてもある一定の抽象度を持ってしまう（=具象度は下がる）

つまり、他のアクターとのバランスをとり抽象化された存在であるはずの SoR が直接誰か向けのインターフェースを提供するということはそのための具象を持たなければならないという自己矛盾したような状況に陥るかなと思ったからです。これがあり得るとしたら経営者とか事業責任者レベルの人を対象としたダッシュボードなど、そのシステムで成し遂げたいゴールそのものを閲覧するためのインターフェースかなと思いますが、そうでなければ何らかのユースケースがあり、そのユースケース向けの具象を持つことになるような気がします。

ただ、一方で次のようにも思っています。

  • ドメインモデルがどの程度抽象的かは設計判断の帰結であり、十分に文脈が絞られたドメインモデルもあるはずと思う
    • 僕はこれを「ドメインモデルのプラットフォーム性」とか呼びます。
  • ドメインモデルがすでに広く知られている別のモデルと近いか、それを前提にしている場合、利用者に浸透しやすくドメインの語彙がそのままユビキタス言語になる可能性がある（=コンテキストマップの構築コストが低い）
  • そのようなケースで、SoR と SoE が共通のユビキタス言語を持つ（ように見える）ことはあり得るし、自ずと UI にもそれが現れる

今回お話した EC の例だと、たとえば広くあまねくあらゆる商品を取り扱うプラットフォームを目指すのか、家電だけを取り扱うのかによってドメインモデルは違ってきますし、後者の場合は家電に固有の知識が SoR に現れます。前者がプラットフォーム性の高いドメインモデルで、後者がプラットフォーム性の低い（=具象度の高い）ドメインモデルですね。そして、このプラットフォーム性が高いほど SoE 側のモデルの変換コストは高くなりがちですし、逆に低いほどドメインモデル上の語彙がそのままプレゼンテーション（UI）にも現れやすいと思います。

そしてこのプラットフォーム性、一般に立ち上げ初期の事業リスクが高いときほど低く、スケールするごとに徐々に高まります。これについては事業ロードマップを適宜共有してもらいながら設計判断に落とし込むべきではありますが、過度に折り込みすぎると YAGNI だと言われてしまいます。なので、中央にあるドメインモデルのプラットフォーム性が高まったときにそいつが UI まで提供してしまっていると影響範囲が大きくなりすぎるのではないかと思い、僕は UI を提供するべきではないと回答したという感じです。

2019/09/03 14:54 追記

qsona さんからご意見いただきましたー！

上述した情報セキュリティ管理基準の話とも絡んでくるかもしれませんが、たとえバックチャンネルであっても通したくない秘匿性の高い情報は SoR が直接受け取るべきで、そのためのインターフェースは提供するべきである、っていう整理になるのでしょうかね。

まとめ

  • 前日（というか、当日の登壇直前）まで緊張していて心理状態はアレな感じだったけど、それでも登壇して本当によかった
  • もっと余裕をもって資料作りましょう
  • 概ね好評で安心しましたし、聞きに来てくれた人には感謝です
  • 大入り賞ありがとうございました
  • 大変よい質問もありがとうございました
  • 登壇楽しい！！

次回

参加レポートスタッフ編に続きます。

*1:最初はこの部分、もっと全然薄かった。

*2:裏番組が少なかったというのもあると思うのですが。

*3:いろいろな設計原則やパターンを挙げ、先人たちの言葉も引用しましたが、中心的な主張はあくまで僕の意見です。