サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
お久しぶりです、かとじゅん(@j5ik2o)です。テックブログを書くのは何年ぶりか…。 サービスが停止したり応答性が低下すると、お叱りや逆に励ましをいただきますが、エンジニアとして設計レベルからそういった問題に対処するにはどうするか、日々精進しているところですmm。この記事はそういう論点で注目されている「リアクティブ原則」についてまとめてみたいと思います。 それなりのボリュームになってしまったので、時間があるときに読んでいただければと思います。 さて、Linux Foundation内の新たなトップレベルプロジェクトであるReactive Foundationが主催する、Reactive Summit 2020が11月10日にオンラインで開催されたので参加しました。 www.reactivesummit.org 参加されていたスピーカーはLightbendをはじめ、Netflix, Fac
これは 設計ナイト2020 の感想記事です。 CQRS とGraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、（レポートというよりも）考えたことを書き残しておきます。 発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。 コンテキスト DDD・CQRS・GraphQL・アーキテクチャの進化戦略などについて深い話（触ってみたレベルでなく実運用等を経たもの）についても興味深かったのですが、サーバー再度にとっての理想的なモデルとフロントエンドの要求が衝突する境界線について考えるきっかけになりました。もしかしてサ
peing.net メッセージングシステムのお題のようです。面白そうなのでちょっと考えてみよう。 問題提起 集約候補が以下の3つ。 ユーザー 企業 スレッド メッセージ スレッド集約はメッセージを複数保持するようです。 1000件のメッセージを保持するスレッド集約を更新した際、1000件のアップデートが行われる スレッド集約内部で更新された属性を把握していない場合は、リポジトリでは全メッセージ分の更新となる。これを避けるための仕組みはどう実装するのか？ ということが指摘されている。まぁわかります。これはCQRS/ESなら解決できるよと言ってみる 問題の分析 で、僕ならどう考えて実装に落とすかつらつらまとめてみよう。CQRS/ES前提です。Akkaの成分は少なめでScalaの擬似コードで解説します。コードはコンパイルしてないので…おかしなところあるかも。 問題はスレッド集約がメッセージの集合
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
![CQRS実践入門 [ドメイン駆動設計] - little hands' lab](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f6a4c5f38eeedeba9c1ce48808acf9444e3af18a4%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fcdn.image.st-hatena.com%252Fimage%252Fscale%252F1d248988cd31ca6b1592926c741fcd58a4621157%252Fbackend%253Dimagemagick%253Bversion%253D1%253Bwidth%253D1300%252Fhttps%25253A%25252F%25252Fcdn-ak.f.st-hatena.com%25252Fimages%25252Ffotolife%25252Fl%25252Flittle_hands%25252F20191202%25252F20191202061944.png&f=jpg&w=240)
TL;DRDockerを用いて以下の環境を用意し、EventStoreの挙動を確認しイベントソーシングの実現方法について検討しました。 EventStoreSampleをcloneしてdocker-compose up すれば動きます。 詳細な使用方法は↓。 はじめに ステートレスアプリケーションでEvent Sourcingするなら、EventStoreを使うとよさそう。仕様をよくみたら、楽観ロック機構もあるようだし実用に耐えれそう。https://t.co/EZu6EsG5VP — かとじゅん (@j5ik2o) 2019年4月24日 にてEventStoreの存在を知ることができました。ありがとうございました。 イベントソーシングとは 書籍だと 実践ドメイン駆動設計 .NETのエンタープライズアプリケーションアーキテクチャ: .NETを例にしたアプリケーション設計原則 ネットだと
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Aecor という純粋関数型 Event Sourcing ライブラリをざっくり紹介したい。 概要 Aecor は Denis Mikhaylov というロシアの技術者が開発した、Scala の純粋関数型イベントソーシングライブラリ。作者が勤務するオンライン予約会社の Evotor 社では、Arcorベースの数十のサービスが実運用されているという。 ラテン語で海の意味で、あえて五十音で近似すると、ラテン語読みだとアエコル、英語読みだとエイカーみたいな感じ。 純粋関数型DDD に親和性が高い。OOP とは逆に、FP ではデータと振る舞いを
背景 集約とリポジトリなどをアプリケーションサービスやコントローラから呼び出し、書き込みや読み込みの要求を実装することがよくあります。ほとんどの場合、トランザクション整合性の観点から考えると、書き込み要求は集約単位になりますが、読み込みは結果整合性も含めると、複数種の集約を合成した、いわゆるリードモデルを返すことが多いです。この記事では、このリードモデルに起こるN+1問題とCQRSの関連性についてまとめたいと思います。 リードモデルを返す処理 みなさんは、どのようにしてリードモデルを構築していますか？ いろいろな方法がありますが、ここでは以下に観点を絞ってみたい。 複数種のリポジトリを使って集約を取得し、リードモデル用DTOに詰め直す リポジトリを使わず、ストレージに対応したDAOで、JOINするような問い合わせを行う 対象のドメイン 話をわかりやすくするために、想定のドメインが必要ですね
wolkenkitempowers you tobuild and runscalable distributed web and cloud services that process and store streams ofdomain events. wolkenkit –build distributed web and cloudAPIswolkenkit is a CQRS and event-sourcing framework based on Node.js.Itempowers you tobuild and runscalable distributed web and cloud services that process and store streams ofdomain events.It supportsJavaScript and
お勉強でTodoListをDDD的流れで作成していたらReactivePropertyが良かったので紹介して見ようと思いました。 以下、作成記録です。 TL;DR ドメインイベントのメッセージ基盤にはMessageBrokerで必要十分。 CQRSのコマンド部はReactiveCommandを継承して実装すれば便利なのでは。 どちらも.NET Standardでも使えるからドメイン層を使い回し可能。 オレオレで作るよりかは良いかと。 ステークホルダーからの要件っぽい内容を定義しておく TodoListを作成したい。 ひとつのTodoをタスクとして管理する。 管理する内容はタイトルと説明とそのTodoの状態。 状態は2値ではなく実行中を含めた3値としたい。 タスクのリストを表示して、ひとつを選択すると詳細な情報が表示されるようにしたい。 タスクを新規に作成するとそのタスクの詳細な情報を入力で
ビジネス ドメインの理解を反映するマイクロソフトサービスまたはコンテキスト境界ごとのドメイン モデルを設計する このセクションでは、複雑なサブシステムへの取り組みが必要な場合に実装する高度なマイクロサービスについて、またドメイン専門家の知識と絶えず変化するビジネス ルールに由来するマイクロサービスについて説明します。 このセクションで使用するアーキテクチャ パターンは、図 7-1 に示すように、ドメイン駆動設計 (DDD) とコマンドクエリ責務分離 (CQRS) の手法に基づいています。 図 7-1。 外部マイクロサービス アーキテクチャとマイクロサービスごとの内部アーキテクチャ パターンとの対比 ただし、ASP.NET Core WebAPI サービスの実装方法や、Swashbuckle または NSwag を使った Swagger メタデータの公開方法など、データ駆動型マイクロサービ
依存関係挿入を使用し、アプリケーション レイヤーにインフラストラクチャ オブジェクトを挿入する 前のセクションで述べたように、アプリケーション レイヤーは、WebAPIプロジェクトや MVC Web アプリプロジェクトなどで作成する成果物 (アセンブリ) の一部として実装できます。ASP.NET Core を使用して作成されたマイクロサービスの場合、アプリケーション レイヤーは通常、WebAPI ライブラリになります。ASP.NET Core から来るもの (そのインフラストラクチャとコントローラー) を、カスタム アプリケーション レイヤー コードと分離したい場合は、アプリケーション レイヤーを別のクラス ライブラリに配置することもできますが、これは任意です。 たとえば、注文マイクロサービスのアプリケーション レイヤー コードは、Ordering.APIプロジェクト (AS
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
Moving Your Bugs Forward in Time: LanguageTrends That Help You Catch Your Bugs atBuild Time Instead of Run Time Chris Price discusses the critical shift from catching bugs at runtime to identifying them during thebuild process. He explains how leveraging modernprogramming language features such as static typing in dynamic languages, null safety, immutable data structures, and exhaustive patter
Money Transfer Saga Part 1 - The Scenario Part 2 - The Implementation Part 3 - The AuditLog Part 4 - Supervision,error kernels and idempotency Part 5 - Results The Saga pattern was first coined by Hector Garcia-Molina and Kenneth Salem in their paper, Sagas. Although originally described in the context of adatabase management system, the Saga pattern has gained popularity in a distributed syste
In this post, I’ve presented a project that is using CQRS and Event Sourcing patterns.It’s organized using onion architecture and written withTypeScript. “flexible” —a free stock photo I found which makes thisblog post much nicer and artistic.“flexible” how?I’m using the term flexible to promote an architecture which is able to adapt to different kind of environments. More precisely, I’m trying
11/18(SAT)にJJUGCCCという、日本のJavaコミュニティの最大規模のカンファレンスで発表してきましたー。1000人を超える申し込みがあるような感じです。そんな場で登壇させていただいて幸せです。 www.java-users.jp 僕のセッションにも 沢山の人が来てくれました。ありがとうございます(∩´∀｀)∩ﾜｰｲ お話しした内容は この記事のタイトルの通り、僕がDDDを勉強したりDomain Event使ってみたいと思ったりKafkaでCQRSの素振りをしている背景と現状についてです。スライドはこちら。speakerdeck.com セッションに参加してない方にも喋った雰囲気が伝わるといいなと思って、コメントを加えたりしてみました。スライド内のリンクをクリックしたい方はSpeaker DeckからPDFでダウンロードができるのでそちらをどうぞ。 デモプロジェクト もアッ
You understand Event Sourcing and CQRS but are you ready for the difficult, complex edge cases in yourdomain? You’re a developer in a .NET/SQL Server shop. Your team has usedDomain-Driven Design in the past with both success and failure. You have a new project.It’s complex -it has requirements that are new to your team and the pressure is on…It as a significant impact on the competitive advan
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
