過大評価されるDDD（ドメイン駆動設計）
この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計（DDD）は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア（TwitterやHacker Newsなど）で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし
ドメイン駆動設計に2年間関わって学んだこと - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに 感想 ドメイン駆動設計との出会い 今ではそんなに悪い奴ではないかなと思えるように 知見 なぜドメイン駆動設計は難しく感じられるのか 原典の重厚さ 導入タイミングの難しさ ドメインエキスパートの協力が得られない ドメインモデルは育てるもの 自社サービスにおけるドメインの捉え方 アーキテクチャには適切なフェーズがある これからドメイン駆動設計を実践する方へ 初めは軽量DDDからでも良い すでにある程度開発が進んでおり、ドメイン知識と技術的負債をコードがたっぷり蓄えているプロジェクト これから立ち上げるプロジェクト おすすめはユビキタス言語から いかにしてドメイン知識を得るか 最後に はじめに こんにちは。logyです。 私は前職で一年と少し、ラクスに入社してから一年間ドメイン駆動設計に関連する開発に関わってきました。 今回は、そこから得られた知見や感想、また、これからドメイン駆動設計
ドメインモデルの根拠とドメインモデル貧血症の対策について - kubell Creator's Note
ChatWork Advent Calendar 2017の10日目の記事です。 こんにちは。かとじゅん([Twitter:@j5ik2o]) です。 何を書こうかと悩んだのですが、社内で意見を聞いたところ、やはりDDD関連がよいとなりました。 Scalaコードでわかった気になるDDD この記事も、もう四年前ですっかり古くなりました。最近どういう観点で実践しているかまとめてみます。(DDD初級者という方は、まず上の記事を読むことをお勧めします) DDDを実践するにあたっての個人的な問題点は2つあります。ひとつは、「いきなりドメインモデルを作ることができない」という問題。もうひとつは、ドメインモデルを作り上げても実装コードに役に立つ振る舞いが思いつかず、いわゆる「ドメインモデル貧血症*1」になりやすいという問題です。このような問題は、僕がコミュニティで関わった多くのエンジニアから耳にします。
Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
ドメイン駆動設計によるシステム開発 | 知的資産創造 | 野村総合研究所(NRI)
システム構築にかかるコスト・期間は20年単位で倍々に増加している。これは「2025年の崖」で示されているレガシーシステムの問題も大きいが、ウォーターフォールモデルで専門家による分業制をとっているシステム開発生産ラインのありようも看過できない。一方、アジャイル開発によるコスト削減や開発期間短縮の効果について、大規模な金融系システムでの実例はまだ少ない。さらに、昨今のマイクロサービスを実現するための設計手法も確立できてはいないと考える。 今回、筆者らチームは「ドメイン駆動設計」を活用し、システム構築コスト・期間を大幅に削減し、かつマイクロサービスに適合するシステム開発の可能性についてのPoCを実施した。
プロダクトにドメイン駆動設計を適用するためにはじめたこと - ContractS開発者ブログ
こんにちは。最近Slackのカスタム絵文字作りにハマっている友野です。Holmesでサーバーサイドエンジニアをしています。 Holmesが提供するホームズクラウドは、今年8月にサービスローンチ3周年を迎えました！ これまでの支持に感謝し、これからも長く使ってもらえるようにプロダクト改善に取り組んでいます。そのひとつとして、ドメイン駆動設計（以下、DDDと表記します）適用に関する取り組みについてご紹介します。似たような状況や同じ課題を持つ誰かの一助になれば幸いです。 背景と現状 まずはじめたこと 戦略的モデリング そして、戦術的な設計 採用するパターン2つ ドメインモデルを反映したオブジェクトを置くパッケージの作成 既存テーブル構造に依存しないRepository+Adapterパターン ふりかえり まとめ 最後に 背景と現状 ホームズクラウドはPMF（Product Market Fit：
ドメイン駆動設計に15年取り組んでわかったこと 「ビジネスルール・値オブジェクト・型」が3つのキーワード
株式会社ビープラウドが主催するIT勉強会「BPStudy」。#151となる今回は、設計の代表格であるオブジェクト指向、モデリング、そして設計にフォーカスをあて、LT大会を開催しました。「ドメイン駆動設計に取り組んだ１５年でわかったこと 」に登壇したのは、ドメイン駆動設計に15年取り組み続けている増田亨氏。ビジネスルールと値オブジェクトと型という3つのキーワードを軸に、ドメイン駆動設計をソフトウェア開発に落とし込む方法論について語りました。講演資料はこちら ビジネス活動に起因する複雑さに立ち向かうドメイン駆動設計 増田亨氏（以下、増田）：よろしくお願いします。私は2006年ぐらいからドメイン駆動設計に実際に取り組んで、15年ぐらいやっているんですけど、今日はそれを私なりにわかったことというか、けっこう最近振り切ってこうやってますよという内容を、みなさんの参考になればと思って少しお話しします。
猿には分からないけど、非エンジニアでも分かると思う、ドメイン駆動設計の「ド」の字くらいだけ説明する - Qiita
はじめに 一度は誰もが調べたキーワード「ドメイン駆動設計(開発)」。 山のように解説記事、ヒットします。開いてみてください。全然意味が分かりません。 ということで、猿には流石に分からないですけど、 非エンジニアの方でも「ドメイン駆動設計」って一体何なのか分かるくらい、 本当に簡単に、そして基礎の初歩の入門だけ説明しようと思います。 筆者もドメイン駆動設計を勉強して、まだまだ浅いので皆様と一緒に 「ドメイン駆動設計」についてもっと考えられたら、 より良い開発ができると考えていますので、何かあればコメントなど頂けると嬉しいです。 そして初めにですが、この記事は引用などはありますが、あくまで私なりの解釈ですので、 これが「ドメイン駆動設計」の絶対的な定義などでは全くありません。 ドメインはドメインであってドメインじゃない 「ドメイン駆動設計」とは何か。まずWikipediaから引用してみます。
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
CQRS実践入門 [ドメイン駆動設計] - little hands' lab
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
![CQRS実践入門 [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/c1461d1de08cfc1309c0a0f3c18a2f498485bb45/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F1a101957924fd716c353278f0d65759b39326613%2Fbackend%3Dimagemagick%3Bheight%3D1200%3Bversion%3D1%3Bwidth%3D1200%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20191202%252F20191202061944.png)
DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - little hands' lab
先日、メディアマックスジャパン様(以下、MMJ様)にお邪魔してドメイン駆動設計勉強会を開催してきました。そちらで質疑応答セッションがあり、実際にドメイン駆動設計で開発をしだしたタイミングで出てきた具体的な疑問について色々お答えしました。 おそらく多くの人が同じような疑問を持たれそうな内容だったので、MMJ様の許可を得てこちらでも紹介したいと思います。 コンテキストの分け方について DBを複数コンテキスト共通でつかっていいのか？ スキーマわけなくていいのか？ コンテキストごとにスキーマは最低限分けることをオススメしています。詳細は以下の記事をご参照ください。 little-hands.hatenablog.com 機能ごとに切る？ユーザ種別ごとにコンテキストわけるべきなのか？ コンテキストの切り方が正しいかどうか、どうやって判断すればいいか？ コンテキスト設計は、従えば作れるようなフローチャ
![DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/d67cd68dc441b5c2938a2fd6c4803d59205f1d65/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F29fa163850cb484329e11acc77a18bde5a3724a7%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20171221%252F20171221134405.png)
ボトムアップドメイン駆動設計
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
何がDDDをDDDにするのか / what make DDD to DDD ?
DDDを学習・実践において多く見受けられる混乱と、それに対する現時点での自分の回答
『ドメイン駆動設計は失敗だ』へのコメント
<blockquote class="hatena-bookmark-comment"><a class="comment-info" href="https://b.hatena.ne.jp/entry/4677766445959872066/comment/Lagenaria" data-user-id="Lagenaria" data-entry-url="https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20191125230444" data-original-href="https://anond.hatelabo.jp/20191125230444" data-entry-favicon="https://cdn-ak2.favicon.st-hatena.com/64?url=https%3A%2F%2Fanond.hatel
僕と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のドメイン駆動設計： エリック・エヴァンスのドメイン駆動設
Laravel vs Symfony（DDDの場合） - Qiita
PHP で DDD（ドメイン駆動設計）をする案件でウェブフレームワークの選定を行いました。 フレームワーク選定にあたり、以下の方針を立てました。 実績のあるフレームワークから選定（Laravel か Symfony の２択としました） DDD が提唱している不変条件をモデルに実装出来ること フレームワークと戦わない（目的達成の為に Hack 等の小細工をしない） 人がレビュー等で注意するといった回避策で妥協しない なるべくシンプルにフレームワークを使う 本来、フレームワークはドメイン層に関心がなく DDD に制約を与えないはずです。 一方で DDD はドメイン層以外には具体的な実装方法を提示していません。 DDD をやるのにどのフレームワークを使ってもいいのでは？と思うのですが、実際にはそうではありませんでした。 フレームワークが採用している ORM によって DDD しやすいものと困難な
ドメイン駆動設計の用語と解説（DDD入門ガイド）
中〜大規模アプリケーションを開発するノウハウを持っておらず、どのようにシステム設計するのが良いのかわからなかった。そのため、1週間ほどドメイン駆動設計（Domain-Driven Design）について勉強した。 当記事では、勉強中に得たドメイン駆動設計をわかった気になれるのに必要な用語のまとめや、実装でどのように使われるかをまとめる。 筆者は「実践ドメイン駆動設計」を読んだわけでも、完全に理解したわけでもない。しかし、雰囲気を掴むための情報はわかっている状況なので、間違っている箇所があったら指摘していただきたい。 ドメイン駆動設計とは？ ドメイン駆動設計（DDD、Domain-Driven Design）を一言で説明すると「現実世界の業務をドメインモデルに詰め込んでソフトウェアに深く反映させる設計手法」だ。 詳しい説明は後述するが、ドメイン駆動設計の全体図は下図のような感じだ。 ドメイン
役割駆動設計で巨大クラスを爆殺する - Qiita
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業の従業員 家族がいる(妻, 子供) 趣味でゲーム制作している ダメな設計 何も考えずに人クラスとして設計すると、よく以下のような構造になりがちです。 従業員として仕事をする、父親として家族サービスする、趣味としてゲーム制作する、それぞれのメソッドが備わってい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsで考えるドメイン駆動設計のコアドメイン
松岡@ログラス/DDD,アジャイル on Twitter: "「DDDのモデリングとは何なのか、そしてどうコードに落とすのか」発表資料です。 (質疑応答の内容と合わせてブログ記事にしました) https://t.co/6aJ9JP7WeY #mixleap"