日本語のドメイン駆動設計 (Domain-Driven Design - DDD) 関連記事まとめ - なにか作る
ドメイン駆動設計は原典となる「エリック・エヴァンスのドメイン駆動設計」の初版が2003年と歴史があり、モダンなフレームワークであればその思想を取り入れた設計がなされているにも関わらず、日本語の情報が少ない気がする。 最近ドメイン駆動設計をやろうと主にWeb上の情報を探っていたので参考になったサイトをリンク集の形でまとめてみる。 概要 概要を把握するのが一番難しいように思うので、色々と目を通すのがよさそう。 little-hands.hatenablog.com enterprisegeeks.hatenablog.com enterprisegeeks.hatenablog.com speakerdeck.com ドメイン駆動設計とは何か 【入門編】 from 増田 亨 www.slideshare.net 3週連続DDDその1 ドメイン駆動設計の基本を理解する from 増田 亨 www
Event Storming and Spring with a Splash of DDD
It is my pleasure to announce that I have just joined the developer advocacy team at Pivotal, focusing on Spring. I feel privileged to have the opportunity to learn and collaborate with great and passionate engineers from all over the world. Hence, I must say I am really excited for the upcoming journey. If you would like to follow me, I tweet under @JakubPilimon and blog here. Before joining Pivo
practice-DDD-with-Scala_en
The Practice DDD with Scala at Scala Matsuri 2018. (日本語版 -> https://speakerdeck.com/crossroad0201/scala-on-ddd) See sample code on GitHub. (Descriptions are Japanese only) https://github.com/crossroad0201/ddd-on-scala 1. What's DDD? 2. DDD with Scala 3. Code Style 4. Architecture - Layers - Error Handling 5. Implement Components - Application Service - Entity - Value Object - Role - Factory - Repo
ドメイン駆動設計を始めるために必要なチームのつくり方
Gunma.web #30のLTで発表した資料です。 どうすればドメイン駆動設計を導入出来るのか、というところにフォーカスにして考えてみました。
実践DDDのサンプルプロジェクトが学びしかない - Mitsuyuki.Shiiba
IDDDを読んで、それなりに書いてあることは分かり始めたかな。と思ってたけど。 いざサンプルプロジェクトを読んでみたら、全然そんなことなかった。(ﾉД`)ｼｸｼｸ github.com いつものように、自分メモ。 プロジェクトの構成 全部で3プロジェクトと1ライブラリがある。 iddd_agilepm データストアとしてKVS(LevelDB)を使用。 DIコンテナは使ってない。 iddd_collaboration Event Sourcing と CQRS。ORM使わずにやってみた。 例をシンプルにするために、Event Sourcedな書き込みモデルと、CQRSの読み込みモデルを1スレッドで実行してる。イベントジャーナルとしてLevelDBを、リードモデル用にMySQLを使ってるのでほんのちょっとだけ一貫性がない状態が発生する可能性がある。別々のデータストアを使って、でも、できるだけ
DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - Qiita
先日、メディアマックスジャパン様(以下、MMJ様)にお邪魔してドメイン駆動設計勉強会を開催してきました。そちらで質疑応答セッションがあり、実際にドメイン駆動設計で開発をしだしたタイミングで出てきた具体的な疑問について色々お答えしました。 おそらく多くの人が同じような疑問を持たれそうな内容だったので、MMJ様の許可を得てこちらでも紹介したいと思います。 コンテキストの分け方について DBを複数コンテキスト共通でつかっていいのか？ スキーマわけなくていいのか？ コンテキストごとにスキーマは最低限分けることをオススメしています。詳細は以下の記事をご参照ください。 境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 機能ごとに切る？ユーザ種別ごとにコンテキストわけるべきなのか？ コンテキストの切り方が正しいかどうか、どうやって判断すればいいか？ コンテキスト設計は、従えば作れるような
![DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d92a52b952ef5df7e0334d4a5eca154940e89277/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9REREJUUzJTgxJUFCJUU5JTk2JUEyJUUzJTgxJTk5JUUzJTgyJThCJUU4JUIzJUFBJUU1JTk1JThGJUUzJTgxJUFCJUUzJTgzJTkwJUUzJTgyJUI3JUUzJTgzJTkwJUUzJTgyJUI3JUUzJTgxJThBJUU3JUFEJTk0JUUzJTgxJTg4JUUzJTgxJTk3JUUzJTgxJUJFJUUzJTgxJTk3JUUzJTgxJTlGJTIwJTVCJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JUU4JUE4JUFEJUU4JUE4JTg4JTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1kN2E4OGYwNmMzNTA2OTVhZjU3OTE0ODU1ZGE1NzUxMg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBsaXR0bGVfaGFuZF9zJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02YmZmYzI2ZTBkMjNhZjllYjRjZTJiYTQwODIzMjhhNA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D97c63c7d634bc5262c5827ed210e2e02)
DDD超入門(後編) - Domain-Driven Designの適用Step - エンタープライズギークス (Enterprise Geeks)
前編ではDDDの概要についてふれたが、後編ではDDDの適用Stepを3つのStepに分けて紹介する。 まずStep1として、アプリケーションに登場しうる概念を抽出してドメインモデルで表現する。 次にStep2として、各ドメインの概念を深掘りしてソフトウェアとしてどう表現するかにについて紹介する。 最後にStep3でドメイン部品の仕上げとDDDの恩恵ついてふれていく。 Step1: ドメインモデルによる表現 DDDでは機能やユースケースに加えて、その裏に潜んでいる「概念」を抽出する必要がある。そのため、DDDを導入するにあたってアプリケーションに登場しうる概念を整理した「ドメインモデル」がまず必要となる。全体のコンテキストを整理して、該当のドメインモデルを描くことがDDDの最初の1歩となる。 例として、よくある一般的な受注管理の簡単なドメインモデルをあげる。 「顧客」からある「商品」の「注文
ドメインモデルの根拠とドメインモデル貧血症の対策について - Chatwork Creator's Note
ChatWork Advent Calendar 2017の10日目の記事です。 こんにちは。かとじゅん([Twitter:@j5ik2o]) です。 何を書こうかと悩んだのですが、社内で意見を聞いたところ、やはりDDD関連がよいとなりました。 Scalaコードでわかった気になるDDD この記事も、もう四年前ですっかり古くなりました。最近どういう観点で実践しているかまとめてみます。(DDD初級者という方は、まず上の記事を読むことをお勧めします) DDDを実践するにあたっての個人的な問題点は2つあります。ひとつは、「いきなりドメインモデルを作ることができない」という問題。もうひとつは、ドメインモデルを作り上げても実装コードに役に立つ振る舞いが思いつかず、いわゆる「ドメインモデル貧血症*1」になりやすいという問題です。このような問題は、僕がコミュニティで関わった多くのエンジニアから耳にします。
境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、
![境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/651dc2c9022ca618fd318e11235cd199205385a3/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171207%2F20171207001225.png)
境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
境界づけられたコンテキストとは 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界づけられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界づけられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界づけられたコンテキスト ・境界づけられたコンテキストをどう実装に
![境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/6bb65ba88fd34a29140629a2f7085b6e005c2663/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171128%2F20171128072027.png)
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計の４つの基本活動、Springのプログラミングモデル、ドメイン駆動設計のためのSpringの使い方Read less
#jjug_ccc 僕がDDDを勉強したりDomain Event使ってみたいと思ったりKafkaでCQRSの素振りをしている背景と現状 - Mitsuyuki.Shiiba
11/18(SAT)にJJUG CCCという、日本のJavaコミュニティの最大規模のカンファレンスで発表してきましたー。1000人を超える申し込みがあるような感じです。そんな場で登壇させていただいて幸せです。 www.java-users.jp 僕のセッションにも 沢山の人が来てくれました。ありがとうございます(∩´∀｀)∩ﾜｰｲ お話しした内容は この記事のタイトルの通り、僕がDDDを勉強したりDomain Event使ってみたいと思ったりKafkaでCQRSの素振りをしている背景と現状についてです。スライドはこちら。 speakerdeck.com セッションに参加してない方にも喋った雰囲気が伝わるといいなと思って、コメントを加えたりしてみました。スライド内のリンクをクリックしたい方はSpeaker DeckからPDFでダウンロードができるのでそちらをどうぞ。 デモプロジェクト もアッ
DDD x 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の選定ポイント ・構築したアーキテクチャ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
集約の設計と実装
Realworld Domain Model on Rails
Introduction to the practice Reactive-DDD
サービス開発における フロントエンド・ドメイン駆動設計の実践
ドメイン駆動設計を軽快に実践するための工夫
Laravelとドメインモデルと永続化モデル @ laravel.osaka #12
Eric Evans氏: ドメイン駆動設計は、以前より以上に妥当性を獲得している
