トーク

関連し合うデータとロジックをひとまとめにして、1つのモジュールを定義することをカプセル化といいます。

正しくカプセル化すると、関心が分離され、変更に強い構造になります。
ところが上手くカプセル化できなかったり、仕様変更により意図せずカプセル化が破られてしまうことが往々にしてあります。
カプセル化が破られると異なる関心事どうしが混在する構造になり、整合性の維持が困難になったり、変更に弱い構造になってしまいます。

本セッションでは、カプセル化の設計が良くないとどんな凄惨な地獄が待ち受けているかを風刺したクソコード動画、『カプセル化 Mk-II』を上映します。
(参考：クソコード動画『カプセル化』 https://twitter.com/MinoDriven/status/1142926621583663104 )
動画の中で何がマズかったのか、高品質なカプセル化をするにはどう設計すればいいのかについて、「目的論的抽象」という抽象化の観点で解説します。
その他カプセル化する上で考慮が必要な観点や、カプセル化に関するよくある誤解などについてもあわせて解説いたします。

近年目にすることが増えてきた「脅威モデリング」、その目的は脅威を特定しリスク判別するだけではありません。そのプロセスにおいてビジネス上の効果を高めるために重要なポイントとその効果を脅威モデリングの概要とともに解説します。

2016年から仕事で、また2017年からは趣味でもプログラミングをしてきた私にとって、変更しやすいコードというのはずっと憧れでした。
自分の書くコードはとにかく変更しづらくて、ハードウェアと呼称していました。
変更しやすいコードを書きたくてオブジェクト指向に興味を持ちましたし、OOC 2020では道中のアウトプットとしてプロポーザルにも挑戦しています。
2020では採択はされませんでしたが、その後も設計についてのインプットは継続し、オンラインで『ミノ駆動本』や『ちょうぜつ本』の読書会も共同主催してきました。

このインプットが多少は結実し、変更しやすいコードを書くコツがいくつか見えてきています。
このトークでは、過去の私に知の高速道路を提供するように、変更しやすいコードを書くコツを共有していきます。

聞く方のイメージは、変更しやすいコードを書きたいと思っているのになぜか書けない、"わからん殺し"されている状況の方です。
私が食らってきたわからん殺しを共有して、何が起こっているかが見えるきっかけになればと思います。
私が習熟しているPythonでコード例を示しますが、ここで話す内容はPython固有ではなく、他の言語でも当てはまると思います

• シンプルさによる変更しやすさ
  • レゴブロックのイメージ（Clojure）
  • 小さなクラスを組み合わせる
• これが、クラス
  • 入門書で見かける文法説明のクラスとのギャップを埋める
  • データとメソッドをまとめた例
  • 悪しき構造：データクラスに注意（私はよくやってました）
• 小さいは、正義！
  • 単一責任と恣意性
  • 入出力と計算を分ける
  • 作ると使うを分ける（依存性の注入）
• インターフェースという概念
  • インターフェースとは、利用時の関心
  • インターフェースに依存させる（依存性逆転）
• 継承
  • 気軽に継承を使うんじゃねえ、そいつは重税だ
  • 継承より委譲
• いま見えてきていること：変更しやすいコードをチームで書く
  • ソフトウェアは一人で作るのではないという（次の壁への）気付き
  • この発表も次の壁への取り組みの1つかなと思います

私がDDDに出会ったのは2014年です。
そのころはDDDの情報も少なく、試行錯誤しながらDDDに向き合ってきました。
思い返すと「DDD理解した」と「DDD分からん」を繰り返してきたように思えます。
今回の発表では私の経験をベースに「なぜDDDが難しいのか」「どうすればできるようになるのか」を設計原則や良いコードの定義を交えて説明しようと思います。

拙著「ちょうぜつソフトウェア設計入門」には、「オブジェクト指向の定義はない」と書かれています。

「オブジェクト指向」という言葉は、その普及とともに、当初意図されていた意味を失い、バラバラの概念に好き勝手に使われるようになってしまいました。さらに時が進むにつれて、私は、オブジェクト指向を自信満々に説明したもの(あるいは強く批判したもの)ほどとんでもない大間違いだという状況を、何度も見ることになりました。入門者にとって、先にオブジェクト指向を理解しようとする道は、もはや罠しかない世の中です。

なぜこんな状況になってしまったのでしょうか。西洋の宗教史と近代化になぞらえて、「オブジェクト指向」という用語がどんな経緯を辿ったのかを探っていきましょう。歴史を知って余計なノイズを取り除くことが、入門からさらに踏み込んでいこうとするみなさんにとって、自分の目で本質を見つけるヒントになるのではないかと思います。

「匠Method」はビジネスデザインの企画手法であり、「RDRA」は要件定義に、そして「ICONIX」と「DDD」はオブジェクト指向設計の手法にそれぞれ特化しています。これらの手法を組み合わせて使用することにより、ビジネスアイデアから設計までの過程をトレーサブル（追跡可能）に保ちつつ、システム全体を俯瞰する考え方を実現できます。

本セッションでは、これらの方法論をどのように結びつけ、総合的な思考へと展開するかについて説明します。

発表資料
https://speakerdeck.com/yuitosato/functional-and-type-safe-ddd-for-oop

ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。

本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。
型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。
さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。

関数型の考えをいれるといってもただ単にHaskellなどに代表される関数型言語を使ってドメイン駆動設計を行うことではありません。
関数型の知識を応用したタイプセーフな考え方やテクニックは小さく導入することが可能です。Javaなどの既存のオブジェクト指向の良さをそのままに明日からプロダクトションコードを改善する手法を紹介します。

1. はじめに
   1-1. 関数型DDDとは？
   1-2. ビジネスロジックを型で表現できると何がいいの？
   1-3. オブジェクト指向と関数型
2. DDDってなんだっけ？
   2-1. モデリングとアーキテクチャ
3. 実践と3つのテクニック
   3-1. モデルの状態を代数的データ型で表現する
   3-2. モデルの状態遷移を型と全域関数で表現する
   3-3. ロジック内のDBアクセスを高階関数で表現する
4. まとめ

オブジェクトたちがおしゃべりする世界、それはまるで魔法のようにシステムを動かすことができる力です。
しかし、その裏にはオブジェクトたちの失言や伝言ゲーム、嘘などの罠がたくさん潜んでいます。
良かれと思って導入した非同期処理のQueueやストリーミング処理で失敗はありませんか？

ネット上にある記事を鵜呑みにしてしまうと致命的なアンチパターンに繋がってしまうことも多くあります。
状態をもたせないイベントでマテリアライズドビュー化してしまう、
巨大なランタイムを持たせてしまったハンドラ、
なぜ時系列通りに処理がされなくなってしまうのか、なぜ処理がスタックしてしまうのか、
更新よりも削除が先に動いてしまうのはなぜ？
シリアライズしたオブジェクトが戻せない、副問合せで状態が変わってしまった・・

あの時、どうすればこうした自体を招かずに済んだのでしょうか。
ちょっとしたきっかけでメッセージを使ったシステムを簡単に壊してしまうことがあります。

このセッションでは、ちょっとしたミスやあるきっかけが招くメッセージングのアンチパターンをユーモアたっぷりに解説します。
アンチパターンから抜け出すための時系列とモデリング、
そしてメッセージのルーティングなどいくつかの武器を手に入れましょう！

キーワード：event sourcing、メッセージパッシング、アクターモデル、Queue、分散処理

クリストファーアレグザンダーの設計についての考察からスタートし、アンクルボブや吉川弘之を引用しながら設計とは本質的に何であるかを解説する。
次に現在主流のAIの教育プロセスと人間の学習プロセスの重要な相違点からAIが得意なこととAIがその原理的にできないことを明らかにする。
これらからAIが本質的には設計はできないということを本セッションで主張したい。
また現在ソフトウェア業界で設計と呼ばれている行為の中にはAIが得意な作業は多く存在している。前述の内容をもとに設計の中でAIをどう活用し、人間は何をすれば効率よう質の高い設計ができるか話していきたい。

暫定アジェンダ

　リファクタリングは設計？
　なぜ設計の本質を考えるか
　設計の語源
　ビジュアルデザインとの分化
　デザイン思考
　ソフトウェアに限定しない設計の全体像

　アレグザンダーの定義
　アレグザンダーの行った実験
　設計の階層性
　ソースコードは設計書か？
　フラクタル
　要求開発
　アーキテクチャ設計
　開発プロセス
　組織設計

　生成AIの仕組み
　人間の学習プロセス
　純粋経験
　設計と純粋経験
　設計行為が行われる際の外部条件
　AIに設計ができない理由

　より良い設計とAIの活用
　ソフトウェア開発において設計が生み出す価値

オブジェクト指向は大切、オブジェクト指向は難しいなどと言われますが、ではオブジェクト指向とはなんでしょうか？実際のところ、広く合意のあるような定義は見当たりません。
ただ、ここではこれからの開発作業をよりよいものにするための話をするべきなので「オブジェクト指向がきっかけだったのだから全部オブジェクト指向だ！」のような過去の栄光のような話をしてもあまり意味はありません。
そこでこのセッションでは、関数型など他のアプローチでも可能なことをオブジェクト指向から分離させていき、そうするとオブジェクト指向として何が残るのか、またそのような中で、今までばくぜんとオブジェクト指向として話されたことをどのように整理して扱うといいのかをお話しします。
内容はWEB+DB PRESS vol.132 「オブジェクト指向神話からの脱却」を発展させたものになる予定です。
https://gihyo.jp/magazine/wdpress/archive/2023/vol132

技術的負債や上がらない生産性に悩まされていませんか？
不確実性に強い関数型DDDを実践することで、高い品質と機動力を手にすることができます。

このセッションでは、関数型の旨味を活かしたドメイン駆動開発とそのアーキテクチャを、関数型DDD（fDDD）と称して紹介します。

関数型DDDでは、問題空間を型で適切に捉え、ドメインをより明瞭に表現します。
コンパイル時にビジネスルール違反をチェックしたり、型の抽象化力と合成力でテストを容易にするばかりでなく、決定を遅らせやすくします。

本セッションでは上記の特徴をご紹介しつつ、
　・オブジェクト指向言語で関数型DDDをするには？
　・オブジェクト指向と関数型はどのように共存するのか？
　・関数型のエッセンスは部分的に取り入れているけれど、開発全体でどう活かしていけばいいのか？
といった疑問にお答えします。

こんなトピックをお話する予定です：

・関数型の何がいいのさ？
・オブジェクト指向からみた関数型、やはりオブジェクトファーストな方がDDDしやすい
・関数型DDDとは
・型でドメインを明瞭にする
・型の合成で柔軟に仕様変更する
・関数型アーキテクチャでテストしやすく、開発を進めやすくする
・「決定を遅らせる」を先に作る、プロダクトに適応力をもたらす
・関数型エラーハンドリングで例外ルートをしっかりチェック

（本セッションは、拙著「ContractS Tech Book Vol.1」の「型の力で高品質にドメインをモデリングする〜関数型DDDに向けて〜」の続編に相当するものを予定しています）