株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p

みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆

Indroduction Xtend, Extending Java, Statically typed, Closure, Extension method

より詳細な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の選定ポイント ・構築したアーキテクチャ

より詳細な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の選定ポイント ・構築したアーキテクチャ

BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/

アジャイルプロセスのXPでもコミュニケーションに重点が置かれますが、その考え方に影響を受けているDDDでも業務担当者とプログラマーとの間のコミュニケーションを重視しているようです。しかし、これは「報連相」「根回し」「場の空気を読む」といった、いわゆる業界の新人研修やOJTで先輩社員から叩き込まれるような人間的なコミュニケーションのことよりは、むしろ、共通の言語やモデルによる科学的なコミュニケーションという点に重点を置いています。もちろん、最終的にコミュニケーションは人間同士で行うものなので、ヒューマンスキルが重要なのは言うまでもないことですが、日本の場合伝統的にチームの和を乱さないとか事なかれ主義のようなところもあり、事実に基づく正直なコミュニケーションが良くないとされるケースが多いようです。つまり、エンジニアとしてよりもむしろ、サラリーマンとしてのコミュニケーション能力が重視されるという

Another violent water metaphor brought to you by the author of DDD! People often ask for more concrete guidance on how to explore models, especially in an Agile or Lean setting. The document you find here is Eric Evans’ attempt to capture in writing a process we have used with clients in various forms and settings for the several years. This is not a development process. It should fit within most

昨日、DevLoveの主催するBeautiful Development（ソフトウェアの核心にある複雑さに立ち向かう）という勉強会に参加してきました。 https://sites.google.com/a/devlove.org/development/past-beneficiaries/devlove_ddd2 今回は、Domain-Driven Design（DDD）をテーマにした勉強会でした。ここで簡単にレポートさせていただきたいと思います。 勉強会参加のすすめ 実は、DevLoveの勉強会に参加するのはまだ今回が2回目です。*1 このように私自身もまだDevLove初心者なのですが、今回は初参加の人がかなり大勢いたようです。*2こういった技術者の勉強会というと、初心者お断りというか、相当の予備知識があったりOSSコミュニティーに貢献したりしていないと参加してはいけないのでないかと

システム開発における言語的要素の重要性について、書籍を参照しつつ私見を整理する。 導入 世の中には「文系プログラマ」という表現がありますが、私もそのカテゴリに入る人間です。それも文系度はかなり高く、文学部でいわゆる思想史的なことを勉強していたんですね。文系の思想研究とソフトウェア開発との間には、かなり深い溝が横たわっていると思う人が多いですし、私自身も当初はそう思っていたのですが、時間が経つにつれて両者の間には相通じるものが確かにあると考えるようになってきました。それはどちらも本質的には「言葉」を扱うものだということです。特定の処理はどう実現するかよりはむしろ、どう表現するかという問題であるということですね。より正確に言うならば、この実現手段と言語的表現を限りなく近づけることができるパラダイムがオブジェクト指向である、ということなのかもしれません。 特定の抽象度からある概念を捉えること。そ

Eric Evans氏の名著"Domain-Driven Design"第17章より、戦略的デザイン（"Strategic Design"）のためのエッセンスをまとめた部分について要約とコメント。 Six Essentials for Strategic Design Decision Making 決定はチーム全体に行き渡らなければならない 戦略はメンバー全員が知る必要がありますが、かといって中心にすえられるのが「象牙の塔のアーキテクト」だとうまくいきません。コミュニケーションがうまくいっているプロジェクトでは、アプリケーションチームから発生した戦略的デザインこそが全体に行き渡り、正しい意思決定をする上での権威を持ちます。どんなシステムであっても大切にしなければいけないのは、マネジメントによって与えられた権威よりも開発者が戦略に対して持つ実際の関係なのです。 決定のプロセスはフィードバッ

「Model View Controller」や「モデル駆動」など、ごく当たり前に使用されるようになった「モデル」という言葉をDDDに準拠しながら再考する。 導入 「オブジェクト指向」「モデル駆動」「ドメイン駆動」という表現はすっかり日本語として定着しており、ある一定の共通認識も出来上がってきているように感じます。しかし、「オブジェクト」「モデル」「ドメイン」という概念が本当にきちんと日本語としての文脈の中に位置づけられているのかというと、結構怪しいことも多いのではないでしょうか。このあいまいさの原因ははっきりしていて、向こうの国で膨大な文脈の中に位置づけられている単語を日本語にすることなく、なんとなくカタカナで表現してしまっていることでしょう。もっとも、この悪い癖は今に始まったことではなく、「エラン・ヴィタール」や「ルサンチマン」に見られるように、それなりの歴史があるのかもしれませんが。

InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architects. View an example Memorial Day Sale: Save up to 60% on InfoQ Dev Summit Boston (June 24-25)

InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architects. View an example Memorial Day Sale: Save up to 60% on InfoQ Dev Summit Boston (June 24-25)