設計ナイト2024 めっちゃ良かった #sekkeinight

2024/06/14に行われた設計ナイト2024というイベントが、めっちゃ良かったので、めっちゃ良かった自慢します。

kichijojipm.connpass.com

良かったポイント1:(当然ながら)セッションが最高だった

どのセッションも濃い!

論より証拠、とりあえずスライド貼っておきますね。

ロジックから状態を分離する技術 / わいとん
www.slideshare.net

コンポーネント設計ってなんだろう / yonekubo
www.docswell.com

なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD / yu_mi0825
(おそらく資料あげられていない)

オブジェクト指向考古学: 人類は再び DCI の夢を見るか / すえなみ
speakerdeck.com

他にLTも5本あり、多いに盛り上がりました。

どのセッションも「こういうケースはこうモデリングしたほうが良い」のようなHowTo的なものではなく、根本に流れる思想や概念(What/Why)に踏み込んだものでした。

それぞれのセッションで抽象化された概念の思想を話して、登壇者が理解した具象を解いてくれるという構成でほとんど共通していたように思えます。これぞまさしく「設計」ってちょっと感動しました。

ここからポエム(クリックで展開) このイベントでのセッションの濃さは、最近ではあまり聞かないような内容に踏み込んでいることにあると思います。

例えば設計の文脈であってもオブジェクト指向の話をする際、どのようにオブジェクトをプログラミングに反映させるかというオブジェクト指向プログラミングをベースに話されることが多かったように感じていました。

ソフトウェアに対してオブジェクト指向の設計原則をいかに適用させるかという多くのプログラマーが実際に課題にフィーチャーしており、オブジェクト指向プログラミングのセッションも当然ながら有用なセッションです。

しかしながらオブジェクト指向を徹底的にやるにはオブジェクトのモデリングとその相互作用という抽象度の高い概念を考える必要があると考えています。そして背景にある、最近ではほとんど話題に上がらなくなった、オブジェクト指向分析やオブジェクト指向設計が重要になってきます。

もちろんそれが実際の開発で役に立つものになるのかは別問題ですし、GUIプログラミング以外の文脈で本当に必要な知識かと問われればNoと言わざるを得ないでしょう。例えばオブジェクトのライフサイクルが極端に短いWebアプリケーション*1では、オブジェクトに状態を保持して、相互作用によって状態を変更していくという思想はあまり効力を発揮しません。そのような背景で、オブジェクト指向から独立した、高凝集/低結合というキーセンテンスの方法論が語られるのはとても健全なことだと思います。

とはいえ、分析や設計をないがしろにして良いというわけではなく、ロバストネス図が書かれなくなったからといって考慮しなくて良い概念になったかというとそうではありません。ある意味、根本としては考えないといけないのに、情報にリーチしにくい状態になっているのではないかと感じています。

その点で今回のイベントは、リーチしにくくなっている状況を打破する画期的な内容だったかと思います。

各セッションについて

ここからは感想を軽く記載します。

ロジックから状態を分離する技術

純粋関数の利点と、アプリケーションを部分的かつ意識的に純粋関数を適用して保守性を高める話でした。

純粋関数は基本的に疎結合になるので、保守性が高まるのは、とても同意できました。

一方で純粋関数用のレイヤー(資料内ではDomainと呼んでいました)の高凝縮性の担保はどうするのか、どこにその関数があるかがわからなくならないかと、純粋関数用のパラメータとしてプレーンなオブジェクトがネックにならないかなという点が疑問に残りました。プレーンなオブジェクトの件は「そんなに引数増やすような設計するな」というので解決しそうな気はします。

コンポーネント設計ってなんだろう

コンポーネントに焦点を当てたセッションで、まずはコンポーネントは何かを4つの引用から提示していたのが印象的でした。

また、コンポーネントは「分析して得られたメンタルモデルの写像」ではなく「メンタルモデルと乖離の少ない設計モデル」を作る、という話も心に残りました。

これは分析の結果が実際に扱う抽象度と合わない可能性があることを示しているように思えます。

なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD

誤解を恐れず言ってしまえば、サボらず、ひたむきにDDDしようという話だったかと思います。

DDDするならチーム内外を含めてプロジェクトの構造も変更する必要があり、ドメイン間で所属が競合しそうな場合は判明した時点で話し合うことが重要とのことでした。

競合しそうなドメイン(すなわち前提の境界位置を疑う事象)は俯瞰的に見れるオブザーバー的な立ち位置がいると良く、「イネイブリングモデラー」と登壇者は呼称しているみたいです。

また「前提の境界位置を疑う事象」を発見する手法も解説していました。

オブジェクト指向考古学: 人類は再び DCI の夢を見るか

ロール指向設計という設計概念の話でした。

オブジェクトはロールの合成であるとして、例えば「ある人」は、固有の基本属性(名前や年齢)と会社員ロール、家族ロール、社会ロール、etc...の合成として考えるというものです。

まとめとして、手続き、アルゴリズムの境界とデータの境界が合わない場合は、ロールを手がかりに設計すると良いという話がありました。

ここはそんなに難しいことを考えずUsecaseレイヤーやServiceレイヤーが解決しているのではないかと、短絡的に考えてしまいました。

そうすると実際にはロール(例示でいう「ある人」)の抽象概念としてのレイヤーではなく、もっと大きなフローの概念になるというのは感じており、このへんがWebアプリケーションでオブジェクト指向は微妙となる所以かなとも思いました。

良かったポイント2:会場(CARTAさん)が最高だった

CARTA HOLDINGSのスペースをお借りしてのイベントでしたが、ここが最高でした。 最高なポイントを列挙します!

(こんなところで働きたいですね!)

良かったポイント3:参加者が最高だった

前述の通り、会場WiFiがあり盛んにXのポストがされていました。

共感はもちろん、登壇者と異なった自分の考え、疑問、あるいは補足情報がリアルタイムにXに投稿され、自分になかった視点や思考から新たな発見が次々と得られる最高の体験でした。

Xでの投稿の様子はまとめられているので興味があれば見てください!!
togetter.com

終わりに

すべて最高なイベントでした!

主催のmagnoliakさんをはじめとして、登壇者の皆さん、スタッフの皆さん、会場を提供してくださったCARTAの皆さん、そして当日参加者の皆さん、素敵なイベントをありがとうございました!

*1:基本的にはリクエスト単位でオブジェクトは破棄され、データストアとのやり取りで状態を保持