従来のイベントソーシングのような手法だと、特定の State（というよりは Entity かも）を永続化するための手段として Event を用いるというような、あくまでも State 中心の発想になると思います。 そこで、ここでは下記のような Event 中心の発想に切り替えて、在庫管理（在庫数を把握するだけの単純なもの）を考えてみました。 State は本質ではなく、Event を解釈した結果にすぎない（解釈の仕方は様々） Event を得たり、伝えたりするための手段として State を用いる 要するに、Event こそが重要で State（Entity とか）は取るに足らない存在だと（実験的に）考えてみたって事です。 従来のイベントソーシング 本件 State が目的、Event が手段 Event が目的、State が手段 なお、ここでイメージしている Event は、特定のドメ
Red Hat 小杉です。 本日はドメイン駆動設計(DDD)と Red Hat について書いてみました。 medium.com ドメイン駆動設計を考慮して設計したいと思われている方は是非 Red Hat にお声がけください。
EventStorming (イベントストーミング) というモデリング手法があります。 www.eventstorming.com EventStorming is a flexible workshop format for collaborative exploration of complex business domains. EventStormingは、複雑なビジネスドメインを協同的に探求するための柔軟なワークショップ形式のひとつです。（意訳） 考案者はAlberto Brandolini氏で2013年にはブログに最初の投稿がされています。 海外での認知度は高く*1、Eric Evans氏のプレゼンテーションの中でも強力な手法であると言及*2されています。 近々、この手法を試せる機会が来そうなので、そのやり方について（私見を交えつつ）まとめてみるエントリです。 注意 現在進行系
ドメイン駆動設計(DDD)に関するアドベントカレンダー。DDDに関することであればなんでもOK。 「エリックエヴァンスの」としてないので、ドメインを扱う設計手法であればOKです。実践ドメイン駆動設計でも、CQRS(Event Sourcing), クリーンアーキテクチャとかでもよいですが、必ずドメイン駆動設計にどう関係するか書いてくださいね。 あと、議論のきっかけにできればよいと思いますので、入門的なこと・高度なこと・成功したこと・失敗したこと・改善の余地などハードルは下げますので、自由に書いてください。 推奨ハッシュタグ #ドメイン駆動設計 ドメイン駆動設計 #2 Advent Calendar 2018 もあります！ https://qiita.com/advent-calendar/2018/ddd-2
The smartest approach to collaboration beyond silo boundaries EventStorming is a flexible workshop format for collaborative exploration of complex business domains. It comes in different flavours, that can be used in different scenarios: to assess health of an existing line of business and to discover the most effective areas for improvements; to explore the viability of a new startup business mod
[CEDEC 2021] 運用中タイトルでも怖くない！ 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例
前回記事：IDDD本の第3章「コンテキストマップ」の解説 本稿で紹介するアーキテクチャの種類 エバンズ本では、DDDのアーキテクチャは「レイヤアーキテクチャ」を中心に紹介していました。これに対してIDDD本では「ヘキサゴナルアーキテクチャ」を提唱しています。さらにヘキサゴナルアーキテクチャと関係が強い「サービス指向（SOA、REST）」「コマンドクエリ責務分離（CQRS）」「イベント駆動アーキテクチャ（パイプ＆フィルター、長期サーガ、イベントソーシング）」といった概念やアーキテクチャ方式についても取り上げています。 特定のアーキテクチャに依存しないDDD DDDは特定の技術に依存していないため、自由にアーキテクチャを選択することができます。アーキテクチャの選定においては、構築するシステムに求められる「機能要求（ユースケース、ユーザーストーリー、ドメインモデルのシナリオ等）」と「品質要求（性
The document describes setting up a Grails application with domain classes, controllers, and MyBatis integration for database access. It includes: 1) Creating a Grails application, domain class, and scaffolding controller. 2) Configuring plugins and dependencies for Spring Boot and MyBatis. 3) Defining domain classes for Book and ISBN with constraints and mappings. 4) Implementing mappers and XML
超久しぶりのブログ…。 Octopressに疲れたのではてなブログに戻ってきました(Octopressの過去の記事ははてなブログにインポート済です)。ついでプロに移行。 さて、海外のDDDコミュニティではCQRS+Event Sourcing(以下, ES)が人気なのですが、ようやく日本でも話題になることが多くなったので今回は教材となりそうな書籍を簡単に紹介したいと思います。 DDD といえば まず エリック・エヴァンスのドメイン駆動設計 (以下 DDD本) を読むべきですが、CQRSについては記載がないので 実践ドメイン駆動設計 を読みましょう。 実践ドメイン駆動設計 作者: ヴァーン・ヴァーノン出版社/メーカー: 翔泳社発売日: 2015/03/19メディア: Kindle版この商品を含むブログ (2件) を見る さらにDDD本には ES の基礎となる ドメインイベント の解説が含まれ
Aws Dev Day2021 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)
概要 モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。 端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。 DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。 エンティティ
『エリック・エヴァンスのドメイン駆動設計』は、2003年の刊行だったにもかかわらず、大型ソフトウェア構築時につきまとう不透明感を払拭するための指針として現役技術者に多大な影響を与えた。ある意味、エリック・エヴァンスの先見性によって、今日、必要とされるパタン／アンチパタンが整理されていたためだ。 とはいえ、それからすでに11年。ベースとなるオブジェクト指向はそれほど大きな変革はないものの、この10年の間にコンピューティングの対象は大きく増え、さらにドメイン駆動設計をコトバでは知っているものの、経験値のまだ低い技術者の増加もあり、理論だけではなく現状に則した形で体得する必要性が増している。 本書はDDDの考え方はもちろん、コミュニティや実際のビジネスシーンのなかから実践的な方法論を精錬し、いわば21世紀（初頭）型ドメイン駆動設計を伝授するものであり、現在のニーズに合致する内容で構成されている。
若干、難しい話ですが、設計力を上げたいプログラマ向けなエントリ。私も道半ばです。一緒に考えていただければ幸いです。 堅牢なアプリケーションを実現する上で「副作用を最小限に抑える」という設計思想は、非常に重要な示唆を含んでいます。 その「副作用」とは、そもそもどんな定義なのでしょうか。 DDDでは"side effect"と定義していて、以下のように解説されています。 Domain-Driven Design: Tackling Complexity in the Heart of Software: Evans, Eric: 8601300201665: Amazon.com: Books エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon P250より引用 In standard English, the term side effect implies
始めよう! ドメイン駆動設計＆マイクロサービス開発 ～C# と Azure Service Fabric で最高の DDD 開発を～
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
