0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
NTTコムウェア C+ | ITジャーナリストや現役書店員、編集者が選ぶ デジタル人材のためのブックレビュー 第5回：『エリック・エヴァンスのドメイン駆動設計』、『エンタープライズアプリケーションアーキテクチャパターン』
ソフトウェア開発において、使いやすいクラスやコンポーネントを設計するのは難しい。とりわけ大規模になると複雑怪奇になりやすい。そこで先人の良い知恵はないかと探してみると、「ドメイン駆動設計(Domain-driven design, DDD)」というソフトウェア分析・設計・開発技法があり、長きにわたって広く支持されていることがわかる。 本書は、このDDDに関する原典であり、原点とも言える。 DDDはある程度知っていたり、実際に使っていたりしても、本書を読んだことのない方も少なくないだろう。しかし、残念ながらそのような方には本書が語るDDDのエッセンスが伝わっていないことが多いのではないか、という懸念がある。 DDDにはさまざまな側面がある。現在は「第2部モデル駆動設計の構成要素」で紹介される一種のアーキテクチャ技法としての側面が広く知られている。だが、実はDDDの核心はそこにはない。 本書が
DDDリファレンス 定義とパターン概要 (鋭意修正中, CC-BY)
Eric Evans "Domain-Driven Design Reference -- Definitions and Pattern Summaries" の日本語訳です。なかなか見直しと修正（推敲）が終わらないので、とりあえず公開してみます。 https://www.domainlanguage.com/ddd/reference/ ## 翻訳について パターン名については原則として『エリック・エヴァンスのドメイン駆動設計』（翔泳社）に合わせています。素晴らしい訳業に（元「DDD難民」の一人としても）記して感謝いたします。 ただし、「エンティティー」「メタファー」「レイヤー」「ファクトリー」など、末尾の音引きは省略せずに記することにしました。そのため、厳密には正確に同一ではありません（他にも「インタフェース」は「インターフェース」にしています）。ご了承ください。 ## 権利について
【読書感想文】ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 | DevelopersIO
ドメイン駆動設計には興味を持ちつつエリック・エヴァンスのドメイン駆動設計は数年前に積んだまま、という状態で何年か立ってしまったのですが、新しくDDD の本が出ていたので読んでみたところよかったので紹介させていただきます。 ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 本書は、 『エリック・エヴァンスのドメイン駆動設計』（ISBN978-4-7981-2196-3、翔泳社）、 『実践ドメイン駆動設計』（ISBN978-4-7981-3161-0、翔泳社） に感銘を受けた著者が贈る、ドメイン駆動設計の入門書です。 （https://www.shoeisha.co.jp/book/detail/9784798150727 より。） というわけで、ボトムアップで理解出来る章立てで書かれたドメイン駆動設計の入門書です。 個人的には、ドメインモデルの組み立てをどうやればいいのか
ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 | SEshop.com
学習しやすいパターンが満載！ ドメイン駆動設計をやさしく学べる入門書！ 【本書の概要】 本書は、 『エリック・エヴァンスのドメイン駆動設計』（ISBN978-4-7981-2196-3、翔泳社）、 『実践ドメイン駆動設計』（ISBN978-4-7981-3161-0、翔泳社） に感銘を受けた著者が贈る、ドメイン駆動設計の入門書です。 【対象読者】 『エリック・エヴァンスのドメイン駆動設計』や 『実践ドメイン駆動設計』をこれから読もうとしている方、 もしくはすでに読んだものの、「もう少しやさしい入門書も読みたい」 と感じているエンジニアの方を対象としています。 【本書の特徴】 ドメイン駆動設計において、実践が難しいものは後回しにして、 理解しやすい実装パターンからドメイン駆動設計の世界に 飛び込んでもらうことを目的としています。 そこで初心者にとって、理解しやすい、そして実践しやすいパターン
効果的にDDDを導入するために気をつけるべきこと - Qiita
DDDはプロジェクトの期待に応えていますか？ この記事を読み始めたということは、あなたはDDDに興味を持っているか、またはDDDを実際に実践しているのでしょう。 最初に、あなたとDDDの関わり方について質問です。 あなたが実践しているDDDは、満足度の高いソフトウェアをユーザーに届けるのに、効果的に機能しているでしょうか？ またはこれからDDDを導入したいと考えているなら、どのようにDDDがあなたの問題を解決するか、イメージできているでしょうか？ どちらかにNoと答えたなら、この記事の内容が役に立つかもしれません。 DDDを学び始めるとき、我々エンジニアは技術的な面に興味が向きがちです。 レイヤードアーキテクチャ(基本だね!) クリーンアーキテクチャ(依存方向は内側だけに向くようにするんだ!) CQRSやイベントソーシングなどの手法(ストレージを分けるのか分けないのか...) モジュール分
関数型言語で DDD - Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# - Shin x Blog
オブジェクト指向言語でドメインモデルを実装することが当然のように行われていますが、Go で開発したり、Haskell で遊んだりしている中で、他のパラダイムの言語で実装するのはどうなんだろうかという想いがありました。 そんな時に出会ったのが、Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# という本です。 概要 構成 ドメインを理解し、モデリングする 端的なフレーズ Database-Drive-Design や Class-Driven-Design との違い 型、型、型 関数型言語による実用例 恐怖のモナド さいごに 参考 概要 本書は、とある会社の受注とその関連業務をドメインとし、モデリングして、実装していくという内容です。紙ベースで行われている業務
僕とDDDとClean ArchitectureとやっぱりDDD - kenfdev’s blog
2022/04/21更新 ふりかえってみて、この記事は手段と目的をごっちゃにしちゃった自分がよくわかる記事です。 DDDは「どうやってコードを書くか」が問題ではありません。その点を勘違いしちゃってるエンジニアの話として、続きを読みたい人は読んでください🙏 DDD（Domain Driven Design）って難しいですよね。難しい難しいとばかり考えていた僕もようやく最近になって少しずつわかってきた気がします。そのきっかけとなった書籍と僕のストーリーを本記事で紹介できたらと思います。 TL;DR Clean Architectureはなんとなくわかる DDDは難しい と感じている人は「Domain-Driven Design in PHP」を読むと道が拓けるかもしれない。 leanpub.com 僕とDDD DDDといえばEvansのドメイン駆動設計： エリック・エヴァンスのドメイン駆動設
【POD】「実践ドメイン駆動設計」から学ぶDDDの実装入門 | SEshop.com
WINGSプロジェクト 青木 淳夫（著） , 山田 祥寛（監修） 商品番号 161500 販売状態 発売中 納品形態 宅配便にてお届け 発売日 2019年05月31日 出荷開始日 2019年05月31日 ISBN 9784798161501 判型 B5 ページ数 184 キーワード 翔泳社デジタルファースト POD（オンデマンド印刷） 翔泳社デジタルファースト（SDF）について 「翔泳社デジタルファースト」は、お客様が注文してから印刷するPOD（オンデマンド印刷）を利用したシリーズです。他では入手できないオリジナルコンテンツを、POD形式でより速く、より手軽に読んでいただくことができます。 SEshopでは、ある程度在庫をご用意しておりますが、在庫状況によりましては、ご注文いただいてから印刷いたしますので、出荷までにお時間がかかる場合がございます。あらかじめご了承ください。 書籍「実践ド
ドメイン駆動設計を理解する３つのキーワード - ソフトウェア設計を考える
ドメイン駆動設計との出会い １０年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。 あまり、面白いとも思わなかった。 当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリング本を参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。 それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。 どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。 バグとの格闘の中で、リファクタリング（設計改善）の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを
「DDD」にまつわる諸課題の整理 - Qiita
DDD的なことを今後進めていく上で、自分として課題としている論点をまとめてみた。あくまで私の現時点での理解度を前提に、そこでの個人的課題感を取り纏めてみたものなので、不足や誤りや過剰が多々あるだろうがご容赦を。そして、アドベントカレンダーの初日、続く議論の礎となり、3人の賢者24人の荒ぶる者によってベツレヘムの星が見出されることをただ願うのである。 ◇ あらまし DDDのいわゆる戦略の言う“広義のドメイン”と、戦術パターンにおける“狭義のドメイン”。この二つの用語は、実のところ「異なる境界付けられたコンテキストに属する語彙」として扱った方がよいのではないか？ 参照系と更新系は、その本質として非対称性があって、参照系向けの新たな戦術パターンが必要なのではないか？ 「コンテキスト」は、強く分離する上位階層から緩く分離する下位層まで、多段階の階層構造に在ると捉えるべきではないか？ （「3.」を前
ドメイン駆動設計の目的は何か - little hands' lab
ドメイン駆動設計の定義についてEric Evansはなんと言っているのか の記事の中で、EricEvansのドメイン駆動の定義を引用して以下のように和訳しました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す この中で、重要なポイントが明示されていませんでした。 定義にある4点のようなことを、なぜやる必要があるのか？ ということです。 つまり、ドメイン駆動設計は、一体何を解決しようとしているのでしょうか？ ドメイン駆動設計は何を解決しようとしているのか DDDはソフトウェア開発手法の一つです。 なのでまず、ソフトウェア開発の目的について考えてみましょう。 人々はなぜ、ソフトウェアを開発するのでしょうか？ それは、
DDDを実践できるエンジニアを育成するための取り組みについて
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.•5K views
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解
![ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed125204d89ae253a4ab2a6c711eff21748ee9c7/height=288;version=1;width=512/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F30489%2F81fcfd95-2ce1-82a8-db69-8618338a5f22.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)
[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほ
![[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/42611ef8213959e1f4a5deb05dd044d24ad9c0e8/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-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCREREJTVEJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JTIwJTJCJTIwJUUzJTgyJUFBJUUzJTgzJThCJUUzJTgyJUFBJUUzJTgzJUIzJUUzJTgyJUEyJUUzJTgzJUJDJUUzJTgyJUFEJUUzJTgzJTg2JUUzJTgyJUFGJUUzJTgzJTgxJUUzJTgzJUEzJUU2JUE2JTgyJUU3JTk1JUE1JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0yMmI3ODA2OTU0ZGI0NWE1NDg5ZGU2NGVlOTliNDJmNg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbGl0dGxlX2hhbmRfcyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9M2M3NjhmN2VjOTAyM2RiNTMyMGEzMjE4ZDU3NGE0NjY%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D84e0fa46680fd317c0a8f5dbe33e43b2)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Takuto Wada on Twitter: "たとえば Eric Evans の DDD 本を読んで「モデリングをやってみたい」と思った人は、消費税の軽減税率制度のモデリングに挑戦するのも面白いと思います。 そこには複雑怪奇な「本物の」ビジネスルールがあります。しかも今年の… https://t.co/iYvHKgbMff"
集約の設計と実装
DDDのユビキタス言語についての考察、研究
DDD失敗談を話して学んだこと
