イベントソーシング（ES）って何？ イベントソーシング（以降、ESと呼ぶ）とは、かなり端的にいうとCRUDにおけるU（update; 更新）とD（delete; 削除）を使わないでアプリケーションのステートを管理する手法のことである。 なぜ使わないかというと、データの更新と削除は本質的に「情報を消し去る」操作であり、消し去った情報が後々ビジネス価値のあるものだと気づいたとしても泣き寝入りするしかないからだ。 ESにおいては、データの更新や削除をするかわりにアプリケーションが管理するステートに対してどのような操作が行われたかをappend-onlyのイベントログに記録していき、ある時点でのステートを知りたいときはアプリケーション側でイベントログの内容を元にステートを導き出すという方法を取る。 CRUDとESの比較 例えば、「ユーザーがパスワード変更する」場合、よくあるCRUDパターンでは u

この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事

こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計（DDD）では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性