データ指向プログラミングの真実を
お話しします
JJUG CCC 2023 Fall
kawasima
データ指向プログラミング
Project Amberの文脈
-
サイズの小さいアプリケーションも扱うようになった。
-
システム全部をJavaで作る訳じゃなくなった
-
オブジェクトではなく、データをやり取りするようになった。
-
そこでプレーンデータをモデル化し、処理するより良い方法が必要
-
代数データ型 (Record, switch式, sealed)
-
https://www.youtube.com/watch?v=eXCx2hW_xNI
Java 21 By Brian Goetz @Devoxx
データ指向プログラミング
書籍『データ指向プログラミング』の文脈
-
コードとデータを分離する
-
汎用データ構造でデータエンティティを表現する
-
データはイミュータブルである
-
データ表現からデータスキーマを切り離す
関数型プログラミングっぽいことを言ってそうだが、
2が決定的に異なる
この両者のアプローチがどれくらい異なるか?
その真実をお話します。
データとは何か
https://news.ycombinator.com/item?id=11945722
Rich HickeyとAlan Kayの議論
データおよび情報の認識のすれ違いまくっている。
データと情報(および知識)の違い
観測、収集したもの
データ
データを利用するために解釈を加えたもの
情報を元に判断したり、別の情報に変換したりする
情報
知識
DIKWフレームワーク
Data, Information, Knowledge, and Wisdom
http://www.systems-thinking.org/dikw/dikw.htm
データと情報は構造の違いではない
例えばメールアドレス"kawasima@wolfchief.jp" はデータであるが、アプリケーションでは解釈によって別の意味を持たせることがある
アクティベーションされているかによってメール送るかどうかが決まる、など。
未アクティベート
メールアドレス
アクティベート済
メールアドレス
また別のコンテキストでは別の解釈がされるかもしれない。
法人
メールアドレス
個人
メールアドレス
区別するにはいくつかのやり方がある
① 構造を変える
② 名前を変える
record EmailAddress(String address, boolean isActivated){}
sealed interface EmailAddress(String address)
permits ActivatedEmailAddress, UnActivatedEmailAddress {
String value();
}
Perspective
データ
情報
情報
情報
解釈
知識
ドメインモデル
Parse
ドメインロジック
ドメインモデル
ドメインモデル
ドメインの外
からの入力
ソフトウェア版
DIKW
DIKW
つまり
-
データに解釈を加えて知識として利用する。
-
解釈の結果を情報と呼ぶことにする。
-
データは一般に多様な解釈がされうる。
これで、2つの「データ指向プログラミング」を読み解く準備が整った
解釈をどこで実装するか?
書籍『データ指向プログラミング』の場合
functionの中でデータを解釈しながら使う
データ
function
書籍『データ指向プログラミング』(DOP)でのやり方
class SendMail {
private final MailSender mailSender;
private final JsonValidator validator;
void send(ImMap<String, Object> data) {
if (!validator.validateEmail(data).isEmpty()) {
throw new IllegalArgumentException("Invalid email address");
}
if (data.getOrDefault("isActivated", false).equals(true)) {
mailSender.send(data.get("emailAddress").toString());
}
}
}
「アクティベート済みの場合だけメールを送信する」は、アクティベートフラグがtrueの場合のみ、メールを送ることである、という解釈をメソッドの中で行っている。
このスタイルのPros/Cons
- データの解釈のやり方を選べる
Pros
Cons
-
データの解釈がfunctionごとに散らばってしまいがち
-
データをどう解釈するかは、コードの詳細を読む必要がある。
(ドキュメントとそのメンテナンスが命)
→ 残念ながらこのConsの対策まではDOPの書籍には書かれていない。
情報設計をせずにDOPを実践するやり方をNaive DOPと
呼ぶ(ことにする)
Naive DOP
Naive DOPは、レガシー基幹システムに多くみられる。
-
電文をPrimitive型に置き換えただけのDTO
-
このDTOをインプットとして「ビジネスロジック」を呼び出す
-
したがって、解釈は個別の「ビジネスロジック」毎に行われる
※イミュータビリティはたいてい持たないので、その点は異なる
では、なぜ今さらそういうことを言い出しているのか?
Clojureにおけるデータ指向プログラミング
そもそも書籍は「Clojureの思想を他言語でもやってみよう」という話。
だがClojureでは、specを使ってデータの解釈を表明する。
-
データの解釈をspecという形で残せる
-
functionの中で個別に解釈されるのではなく、同じ解釈ならば、それはspecとして共有できる
(s/def :email-address/address string?)
(s/def :email-address/is-activated boolean?)
(s/def ::activated-email-address
(and
(s/keys :req [:email-address/address :email-address/is-activated])
#(:email-address/is-activated %)))
(defn send-mail [email-address]
(if (:email-address/is-activated email-address)
(send (:email-address/address email-address))
(throw (Exception. "Email address is not activated"))))
(s/fdef send-mail
:args ::activated-email-address)
つまりClojureのデータ指向プログラミングは…
-
データの解釈をfunctionの事前条件、事後条件で表明する。
-
同じデータの解釈が重複して散らばるのを防ぐためにspecを定義できる。
単なるバリデーションとは違う、
単なるバリデーションとは!
ホンモノのデータ指向プログラミングをやりたきゃClojureを使おう
解釈をどこで実装するか?
Project Amberの場合
データの解釈を型で表現する
データ
メソッド
※ ここからの話はProject Amberの公式見解ではなく、これまでのJavaのオブジェクト指向の方針と、Project Amberで提供された機能から私が考察を加えたものです。
ドメインモデル
(情報)
これまでと何が違うの?
class EmailAddress {
private final String address;
private final boolean isActivated;
EmailAddress(String address, boolean isActivated) {
this.address = address;
this.isActivated = isActivated;
// validate address
}
void send(MailSender mailSender) {
if (isActivated) {
mailSender.send(address);
} else {
throw new NotActivatedException(address);
}
}
}
データの解釈のためにアクティベートされているかどうかを持つ。が、これはこのクラスの利用者が知っておく必要はない
メールアドレスの実装の詳細を知らなくても、「アクティベート済みの場合だけメールを送信する」を実現してくれる
実装の詳細を隠す
Usecase
が、目論見どおり行かないことも多い。
テーブルにマッピングするために、Repository(の実装)がEmailAddressがaddressとisActivatedから構成されていることを知らなければならない。
このあたりからカプセル化が破綻していくことになりがち…
ドメインモデル
Repository
class EmailAddress {
private final String address;
private final boolean isActivated;
EmailAddress(String address, boolean isActivated) {
this.address = address;
this.isActivated = isActivated;
// validate address
}
String getAddress() {
return address;
}
boolean isActivated() {
return isActivated;
}
実装の詳細を露出させることに繋がる
そうなると利用側でActivateされているかどうかの判定ができる
class UserController {
private UserRepository userRepository;
String showProfile(Model model, String userId) {
User user = userRepository.load(userId);
model.addAttribute("isActivated",
user.email().isActivated());
return "profile";
}
}
例えばメールアドレスがアクティベートされているか?がフラグだけでなく、「休会会員でないこと」も条件に追加しなきゃいけなくなったとしたら…
カプセル化の破れ
(注意深く設計すれば、実装の詳細を隠しておけるかもしれないが)
データの解釈をクラスの中に閉じ込めておくのは難しいこともある。
そもそも、ドメインモデルに実装の詳細を持つのがどうなの?
データの解釈を型として表現する
public class SendMail {
private final MailSender mailSender;
public SendMail(MailSender mailSender) {
this.mailSender = mailSender;
}
public void send(ActivatedEmailAddress emailAddress) {
mailSender.send(emailAddress.value());
}
}
sealed interface EmailAddress
permits ActivatedEmailAddress, UnactivatedEmailAddress {
String value();
}
record ActivatedEmailAddress(String value) implements EmailAddress {}
record UnactivatedEmailAddress(String value) implements EmailAddress {}
Eメールアドレスは、未アクティベートとアクティベート済みに分類でき、アクティベート済みの場合だけ、メール送信できる
Project Amberにそこまでの想いが込められているかは分からないが…
実装の詳細をもたないドメインモデルは実現しやすくなる。
- Record
- Sealed interface/class
- switchによるパターンマッチ
結論: 同じ言葉を使っているが方向性はかなり異なる
書籍「データ指向プログラミング」 | Project Amberのデータ指向プログラミング |
---|---|
型をデータから切り離す。 切り離した「型」はバリデーション用のスキーマ(書籍の中ではJSONスキーマ)として表現する。 データの解釈をどこで実装するかは言及されていない…が、Naive DOPの力学に支配されそう。 |
型でデータの解釈を表す。 Domain Modeling Made FunctionalやGrokking Functional Programming(なっとく!関数型プログラミング)の7章参照 |
データの解釈を型で表現する方向性をもう少し…
そもそもの
「メールアドレス」は「未アクティベート」と「アクティベート済み」が存在し、扱いがことなることがある。
という要求をストレートにモデリングすることが、どう実装するかうんぬん以前に重要
アクティベートフラグは業務の用語(ユビキタス言語)ではない
最終的に「アクティベートフラグ」を実装の詳細として持ち込むとしても、概念のモデル、ユビキタス言語を残しておかないと、仕様理解が難しくなる。
本書のコンテキストでは、複雑とは理解するのが難しい、という意味である
書籍「データ指向プログラミング」より
データの解釈をどこに残すか言及していないのに、「複雑とは理解するのが難しい」という意味というのは…
複雑さの分類
書籍『データ指向プログラミング』が参照しているOut of the Tar Pitに書いてあること
状態
本質的複雑さ
偶有的複雑さ
状態から直接計算する
ロジック
コントロール
導出できる
状態
偶有的複雑さは取り除けることもあるが、
本質的複雑さはソフトウェアの設計の工夫ではどうにもならない
https://tech.uzabase.com/entry/2021/05/20/141950
偶有的複雑さは究極理想環境では無くなるもの
(と考えると良い)
-
どんな検索も一瞬で返すマシンや無限のメモリ空間など
-
絶対に判断ミスをしない設計者
現実にはそういうものが存在しないので、トレードオフを考えつつ意思決定(偶有的複雑さを抱える)ことを決めていく。
偶有的複雑さの例①
取引を集計しさえすれば、現在の残高は求まるので、口座エンティティには「残高」は不要。
…なのだが、実際はその算出にそれなりの計算量が必要なので、口座に「残高」を持たせる。
そうした途端に付随して、
-
残高更新時の排他制御
-
取引の集計と残高のズレのチェック(リコンサイル)
など、発生しさらなる複雑さを生む要因になる。
偶有的複雑さの例②
https://twitter.com/t__keshi/status/1635267214008897537
コントロールフロー
手続き型のプログラミングスタイルだとコード順に依存するので、要求仕様外の思わぬ動作に繋がる。
偶有的複雑さの例③
https://www.slideshare.net/kawasima/ss-255489610
偶有的複雑さの例④
プログラミング言語の制約、慣習、Syntax Sugarが無いことなどによっても発生する。
public class Person {
private final String name;
private final String address;
public Person(String name, String address) {
this.name = name;
this.address = address;
}
@Override
public int hashCode() {
return Objects.hash(name, address);
}
@Override
public boolean equals(Object obj) {
if (this == obj) {
return true;
} else if (!(obj instanceof Person)) {
return false;
} else {
Person other = (Person) obj;
return Objects.equals(name, other.name)
&& Objects.equals(address, other.address);
}
}
@Override
public String toString() {
return "Person [name=" + name + ", address=" + address + "]";
}
// standard getters
}
public record Person (
String name,
String address
) {}
=
recordがない時代のJavaで小さなデータをクラスで表現しようとするのは、コード量が増えすぎて偶有的複雑性が増す
本質的複雑さ、とは何か?
シンプル
複雑
-
1つの役割
-
1つのタスク
-
1つの概念
-
複数の役割
-
複数のタスク
-
複数の概念
https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md
要素数が多いのも「複雑」
要素数が多く、それらが相互作用しあう。
2種類の複雑さ
-
単一のコンポーネントに内包される複雑さ
-
1つのエンティティ、1つのクラス、1つのfunctionに複数の責務・概念が混ざっている。単一責任原則(SRP)に違反した状態
-
Unknown Unknowns (理解困難) [A Philosophy of Software Design]
-
-
コンポーネント数が多いことによる複雑さ
-
エンティティやクラス、functionの数が多く、それぞれの役割や関係性を理解するのが厄介。
-
認知負荷が高い (把握難しい) [A Philosophy of Software Design]
-
これらは相互に変換可能
本質的複雑さ保存の法則
巨大なエンティティや巨大なクラスを、1つの責務・概念に分解しても、本質的複雑さの総量が変わるわけではない。
これが「銀の弾丸はない」の本質!
だが理解可能性の非対称
❶の注文には、どういう概念が含まれるか分からない。
【PR】本質的複雑さとうまく付き合う
ためのデータモデリング【宣伝】
複雑とは理解するのが難しいの対策は、
- 複数の概念が含まれないようにデータの解釈、振る舞いを分解する
- 数が多くなったデータの解釈、振る舞いを分割統治する
(Bounded Contextなどがこれに相当する)
ことが必要であり、データと振る舞いを分離したら理解しやすくなるわけではない
ただし、シンプル化し把握したデータの解釈と振る舞いを、どう実装するかは、型や関数を分けることによって生じる偶有的複雑さとのトレードオフを考慮する。
まとめ
つまりコードの詳細を読まずに仕様を理解できるためには、
モデルに含まれる概念(データの解釈)が明らかになっていること
が必要である。
そのためには
-
データの解釈ごとにエンティティや型を分ける
-
それができない場合は、ドキュメントなり何なりに明示しておく
のいずれかが必要
どちらのデータ指向プログラミングを実践するとしても注意しましょう
データ指向プログラミングの真実をお話しします
By kawasima
データ指向プログラミングの真実をお話しします
書籍『データ指向プログラミング』とJavaのProject Amberのデータ指向プログラミングの違いについて真実をお話しします。JJUG CCC 2023 Fallの発表資料です。
- 13,187