ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP

Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。 本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。 型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。 さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。 関数型の考えをいれるといってもただ単にHaskellなどに代表される関

[aike]

合法な状態を型として定義すると型チェックで違法な状態をはじけるというメリットは理解した。ただそれが型の本来的な目的なのかどうかよくわかっていない。状態＝型なのか状態を表現するのに型を流用しているのか。

[roshi]

コンパイル時に教えて欲しいほどビジネスロジックが流動的なら設計段階でもちっと固めてから実装に移りたい気もしたりする（笑）

[knj2918]

再考

[Flume]

ぜんっぜん話は違うしかなり前の話なので今更だが、Javaにvar導入したのはまじでクソだと思ってる/Javaはタイプセーフが売りだったろ？どうなっとるん？って当時思った記憶がある。型推論のためとか言われたらまあ仕方な

[sumomo-kun]

型は本質的に計算可能かを判定するためのものなので、この使い方は不自然じゃない。ただ、世のサービスの仕様はそこまで厳密ではないからか知らんけど、結局DDDはうまくいかないことが多い気がする。

[syu-m-5151]

理解した気がするけど実践が伴っていないので何も言えない。

[tekmak]

項目が増えた時はチェックできないかもしれないけど確かに状態で型変わるね

[medicalcloud]

いいと思うけれど、使う場所を選ぶ気がするな。あんまりあちこちでやりすぎると、クラスが増えすぎる気がする。

[versatile]

主張がシンプルで好感がもてます

[shunkeen]

どうでもいい重箱の隅の話だけど、集合の直和の形式的な定義に違和感。ベクトル空間の直和か何かと混同してるのかな？「A⊕B=A∪BただしA∩B={0}」と書いてあるけど、集合の直和なら「ただしA∩B= {}」だよね？？

[onesplat]

ええな

[nhayato]

リアルタイムで聞いている / スタッフのため途中入場・退出したが、JJUGのときよりも進化していてよかった

[nakag0711]

nullableの件は正規化そのものだね。DBアクセスをコールバックに外出しするのは、理屈からいえば正しいと思うが、実際コードもテストもかなり煩雑になったりしないだろうか？

[t_otoda]

👍 まだわかった気になっているので、アレコレ真似してみたい。