. ├── application │ ├── external │ ├── query │ │ └── user │ │ ├── UserQueryModel │ │ └── UserQueryService │ └── service │ └── user │ ├── UserApplicationService │ └── UserGetOutput ├── domain │ └── model │ └── user │ ├── User │ └── UserRepository ├── infrastructure │ ├── external │ ├── mysqlrepository │ │ └── user │ │ └── UserMySQLRepository │ └── mysqlquery
株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。この記事は私たちジェイテックジャパンの作成しているイベントソーシング・CQRSフレームワークがリリースされてしばらく経ったので開発に至るきっかけやこれまでの歴史をまとめてみました。 Sekiban開発に至る経緯 複雑さに対応するアーキテクチャの必要性 当初、私たちはシンプルなMVCで開発を行っておりました。しかしながら、Fatコントローラーが生じる問題や、モデルにビジネスロジックをまとめる難しさから、メンテナンスが困難なシステムへと変化してしまいました。 そこで、弊社ではDDDというドメイン駆動設計を導入しました。初期段階では「軽量DDD」もしくは「とりあえずレイヤー化したオニオンアーキテクチャ」でした。しかし、リポジトリの抽象化によって、コードのテストが劇的に書きやすくなりました。また、多くのビジネスロジックがドメインに
イベントソーシングは複雑で、導入障壁が高いと思っていませんか？しかし、ドメイン駆動設計（DDD）と組み合わせることで、システムの複雑さを扱いやすくし、柔軟な開発を実現できます。本セッションでは、イベントソーシング・CQRSとDDDの共通点と、それがもたらすメリットをわかりやすく解説します。具体的には、関心の分離や変更への対応力の向上など、開発現場でどのように役立つのかを、実際の事例を交えて紹介します。イベントソーシングをこれから始めたい方や、DDDをより深く理解したい方におすすめです。
こんにちは、データエンジニアの @masaki925 です。 今年の春リニューアルされたスタディサプリの中学講座にて、レコメンドシステムを新規構築しました。 そのアーキテクチャが、当初意図していなかったものの、結果的にはCQRS (Command Query Responsibility Segregation) パターンと呼べるものになっていました。 本記事では、CQRS の特徴に則って当該アーキテクチャを紹介しつつ、今後に向けて考察します。 CQRS パターン + イベントソーシング なぜCQRS + イベントソーシングか 1. 分析用の学習ログと、レコメンドシステム用の学習ログは分けたい 2. 直前の学習状況をリアルタイムに反映したレコメンドをしたい 3. レコメンドロジックはルールベースで開始し、ログが溜まったのちに機械学習(ML) ベースに移行したい 4. 学習ログはスナップショ
「アーキテクチャを突き詰める Online Conference」にてお話した内容です。 CQRS+ESについてナラティブにしゃべるためのスライドなので、特に前半部分はわかりづらいかと思います。 ご了承ください。 ◆ URL Twitter: https://twitter.com/nr…
この記事は弁護士ドットコムアドベントカレンダー 20日目の記事です。 昨日の記事は@amashigeseijiさんのタスクベースUIとCQRSでした。 はじめに @amashigeseijiさんが上記記事投稿後、以下のようなつぶやきをしていました。 タスクベースUIってハイパーメディアコントロールじゃないの?とかの話題もあるけど、時間かけなきゃ書けない... — 天重誠二 (@tenjuu99) December 18, 2020 本記事では@amashigeseijiさんに変わり、上記の「ハイパーメディアコントロールじゃないの？」という点について簡単に解説していきます。 ですので、上記を先に読んであることを前提にしている部分も多少あります。面白いので先に読んでからが良いと思います。 Task-Based UI 以下はCQRS Documents by Greg YoungのFigure7
CQRS/Event Sourcingは、非機能要件の側面で注目されがちですが、本来はDDDのための設計パターンの一つです。 今回は言語非依存に実装する方法を共有しつつ、一緒に手を動かして理解できるようするハンズオン用セッションです。 想定条件 コードを書きたい人はPCをご持参ください 事前にソースコードとセットアップ手順を共有します。あかじめセットアップし動作確認可能な状態でご参加ください。 対象言語でFizzBuzz以上のプログラムが書ける開発者向け ※難しいコードは書きません。手本のコードは共有します。 参加者はプログラミング言語としてGoもしくはRustの好きな方を選択できます ※このセッションを受けると他の言語でも実装できるようになります 想定データベースとしてはコマンド側がDynamoDB、クエリ側はMySQL(RDS) 実装ではREST API,GraphQLを使うのでその経
猫でも分かる UE5.0, 5.1 におけるアニメーションの新機能について【CEDEC+KYUSHU 2022】
イベントソーシングやCQRSパターンの実装では、しばしばアクターモデル（Akka/Pekkoなど）が用いられますが、本セッションではそれに頼らない実装方法を解説します。Amazon DynamoDBを使ったイベントストアの実装方法を中心に、実際のコードを交えながら説明します。
みなさん、CRUD はご存知でしょうか？ Web エンジニアの方なら、学習を始めた最初の頃から聴き馴染みのある言葉だったりするかなと思います。 Create, Read, Update, Delete の頭文字をとったもので、データ操作の 4 つの基本操作です。 例えば RESTful API の場合、下の画像のように HTTP メソッドを対応させて CRUD を表現するのが一般的です。 しかし、CRUD の中で R とそれ以外ではかなり特性が違います。 UI で想像していただければと思うのですが、Read は一覧画面や詳細画面であり、頻繁に呼び出されます。また、多くの場合リクエストごとに挙動が変わるわけではないので、キャッシュが有効です。フィルターや検索もよく使われます。 一方の Create, Update, Delete では、トランザクションが重要視されます。また、アプリケーション
Chatwork に所属するエンジニアや外部ゲストなど、多分野のエキスパートたちの登壇を通して、エンジニア組織で取り組んでいる試みなどの知見を提供する「Chatwork Dev Day 」。ここで開発部テックリードの加藤氏が登壇。続いて、CQRSについて紹介します。前回の記事はこちらから。 なぜCQRSなのか加藤潤一氏（以下、加藤）：「なぜCQRSなのか」という話がありますが、自律性を表明することがあって。「独立して行動し、協調的に相互作用するコンポーネントを設計する」という考え方があります。どういうことかというと、自律性って、結局ほかのサービスと独立して機能しないと意味がありません。 マイクロサービスの動作保証は、連携しているほかのサービスと直接関係がないように、常に自分のサービスの行動を保証するだけという原則があります。ドメイン境界で割っていくと、それぞれ独立したコンテキストでシステム
私のチームでは Event Sourcing と Hybrid-CQRS を採用してプロダクトを開発しています。なぜ Event Sourcing、Hybrid-CQRS を採用したのか、実際に開発してみてどうだったのかを共有することで、なにか参考になるところがあればと思います。 なぜ Event Sourcing と Hybrid-CQRS なのか 私の開発するプロダクトでは、多くのデータがバージョンを持ち、異なるバージョンへの結びつきがあるなど、仕様が複雑になることが予想されていました。データをどのように表現するか検討したときに、異なるバージョンが入り組んだデータを 1 つのデータモデルで Write と Read を兼ねるのは複雑すぎると判断し、データモデルを分けることにしました。 データモデルを分割する際に、同一のデータストアを使用しながらコードレベルでオブジェクトを分割するか、デ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
