ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
Chat GPT-4にDDDのドメインモデルを考えさせたら凄かった件
バックエンド兼インフラエンジニアのrevenue-hackです！ DDD(ドメイン駆動設計)でドメインモデル考えますよね？ その時にGPT-4にやってもらったらどうなんだろう？とふと思い、実際にユースケースからドメインモデルを作ってもらいました！ ↓記事移行しました！↓
ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ #builderscon
Builderscon Tokyo 2019 の発表資料です。
強いて言えば「集約どう実装するのかな、を考える」会に参加してきた - 天の月
architect-club.connpass.com こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 会の概要 会の様子 導入〜よくあるアイテム追加処理〜 ドメインモデルのトリレンマ トリレンマの具体的な実現方法 完全性+性能を取る場合 純粋性+性能を取る場合 完全性+純粋性を取る場合 トリレンマから分かる教訓 高凝集 ドメイン貧血症の解決策で勘違いしがちなこと Domain Modeling Made Functional martin fowlerのドメインモデル貧血症 会全体を通した感想 会の概要 以下、connpassページからの引用です。 部門に社員を配属するとか、カートに商品追加するとか、コレクションを集約としてアイテムを追加する訳だが、件数多くいちいちコレクション全体をメモリにロードしてられないこともある(というかそういうケースの方が多いのでは
集約の実装について考えてみた
はじめに DDD の集約の実装について考えたことをまとめます。 題材 料理のレシピ作成を題材としてまとめていきたいと思います。 概要 概要は以下の通りです。 レシピには材料と作り方がある。 材料には食材や調味料などの名前と分量が必要である。 材料はメインとなる材料や合わせダレなどのカテゴリごとにグルーピングできるとよい。 作り方は具体的な手順を示すものである。 ドメインモデル 上記をドメインモデルで表現するとこのようなイメージです。 各種値の範囲はドメインとして決まっているわけではないですが、システム化する上で決めなければならないことだと思いますので、ドメインエキスパートとすり合わせながら運用に支障をきたさない範囲で決定すると良いのかなと思います。 今回は決定した値の範囲をドメインモデルに補足する形で記載しています。 ユースケース システムに対するユースケースは以下の通りとし、末端のユース
DDDの正体は実装パターンとモデリングの組み合わせ - パンダのプログラミングブログ
PoEAA を通して DDD の半分を理解する マーティン・ファウラーの PoEAA を読んでから、DDD のことを考え続けている。今まで DDD の話題はあえて避けてきた。分厚く難解な書籍、増えるコード量、教祖とその信徒たち（MV）、全てをその視点から解釈しようとする試み、少しでも間違えたら求められる自己批判、無知な者に対する SNS 上のオルグ、いつまでも出てこない総括、それでも信じるものは救われる。「一匹の亡霊がIT界隈を徘徊してる。DDDという亡霊が...」 まあ早まらないでほしい。何も DDD こき下ろそうというわけではない。自分の実力不足が主な原因と思い、深入りする前から「わからないもの」と決めつけていた DDD は、PoEAA というライトに照らされてその姿を私の前に姿を表し始めた。それは亡霊ではなく、確固たる手触りのある実体（Entity）だったのである。 PoEAA は
フロントエンドエンジニアが「自分はJSON色付け係」と自虐する理由を考察した - パンダのプログラミングブログ
「JSON色付け係」という自虐 フロントエンドエンジニアの間では、「私の仕事は JSON に色を付けることです」という有名な自虐ネタがある。 おそらく初出は以下のツイートなのだろう（*1）。ただ、出典はあまり詳しく調べていない。 初めてこの言葉を見た時、面白い言い回しだなと思った。確かにフロントエンドの仕事にそういう側面はある。 実際、コンテンツの表示がメインのページで作業すると上記のような気持ちになる。この場合、フロントでやることといえばせいぜい日付の表示形式を適切にフォーマットするくらいだ。結局バックエンドからデータが返ってこないとフロントだけでは何もできないと思うこともある。 もちろん、フロントだけで簡潔する手書き風グラフ作成ツール excalidraw のようなものは別だし、フロントで複雑な状態を扱う部分を書いたり、フォームを使ってユーザー入力を受け付け、入力値を検証するバリデーシ
ドメイン固有型(値オブジェクト含む)を再考する - かとじゅんの技術日誌
Value Objectが盛り上がっているらしい。 Value Objectについて整理しよう - Software Transactional Memo Value Objectの説明に異論がないものの、主題はValue Object Obsessionのほうですよね。 こちらも聞いてみた。 fukabori.fm よい機会なので、よくわかっているつもりの、値オブジェクトというかドメイン固有型について再考してみよう。 それは値か属性か それはエンティティの全メンバーやデータベースの全列のために「顧客郵便番号」「送付先郵便番号」「事業所郵便番号」「契約日」などのクラス(メンバではなくクラス！)を定義して、immutableな振る舞いを強制する事を以てValue Objectであると言い張り、ドメイン知識の断片をそれぞれのクラスに書き散らして「高凝集になった」「型システムが守ってくれる」と喜
2021年の「オブジェクト指向」を考える
きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない（でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない）というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた（ような気がする）単語が「オブジェクト指向」
実践！ Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog
対象読者 マイクロサービス化を検討しており、実際に作る場合の構成を参考にしたい。 ドメイン駆動設計について、基本的な用語の知識がある。 TypeScript を多少触ったことがある。理解がある。 はじめに こんにちは。エンジニアの吉村です。 現在、弊社が運営する teratail というサービスに携わっており、CakePHP で動作しているモノリシックな既存サービスをマイクロサービスに移行するというプロジェクトを進行中です。 この記事では、実務を通して得た知見として、マイクロサービス化によりどんな恩恵があるのか、具体的にどのような構成で実装をしているのかについてご紹介します。 TL;DR マイクロサービスのバックエンドサービスの実装に焦点を絞って、ドメイン駆動設計 + オニオンアーキテクチャをベースに設計をしました。 本記事では、具体的に「ユーザ新規登録処理」の実装をする場合を例にとり、実
Full-Stack JavaScript meets DDD. - Qiita
これは 2020-01-10 に開催された、DDD meetup#3 でのLTの内容を記事化したものです。 Vuex+Express環境でどんなアーキテクチャを採用したか、して良かったこと／悪かったことを発表しました（LT資料はこちら）。 問題提起 フロントエンドでDDDを実践しようと考えて、結局採用を見送った経験のある方は以外に多いのではないでしょうか。ドメイン知識はバックエンドに集中させてフロントはできるだけライトウェイトに…。と、がんばっても、どうしても気になるものの一つがバリデーション。些末なことだけどバリデーションはれっきとしたドメイン知識。これだけ半端にフロントにいるの、気持ち悪いですよね？ 折角ドメイン知識をその他と分離するなら、フロントとバックでもそれらを共通化したい！できるんです。そう、Full-Stack JavaScriptでの開発なら。 結論 こんなアーキテクチャを
非エンジニアの方に「DDDって何なの？」と聞かれたときの説明[ドメイン駆動設計] - little hands' lab
この記事はドメイン駆動設計 #2 Advent Calendar 2018の16日目の記事です。 DDD(ドメイン駆動設計)とは何なのか そもそもDDDってなんなの？ということをちょくちょく聞かれます。 一言で言うと、「開発手法の一種です」ですが、それだと「ふ〜ん」で終わってしまうので、もう少し興味を持ってもらえる回答を考えます。 まず、開発してて何に困るのかがわからないと思うので、そこから説明をします。 非エンジニア向けの説明 開発手法にも色々あり、行き当たりばったりに作ると以下のような問題に突き当たる、ということがよくあります。 実際の業務をきちんと理解しないで作ったら、 リリースしてもあんまり使われなかったり不評なものができる きちんと整理されてないプログラムを書いたら、 あとから修正するのがどんどん大変になる DDDは、このの2個とも解決しよう、ということで生まれた設計・開発手法な
![非エンジニアの方に「DDDって何なの？」と聞かれたときの説明[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/e3e4fa7f31b58bd9de8ce7f63d37588d4385b09e/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181217%2F20181217062304.png)
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
![新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/da075520c5346bf5227bf90557a35ccf8b5b07ae/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181210%2F20181210195849.png)
DDD基礎解説：エンティティ、値オブジェクトってなんなんだ - little hands' lab
はじめに DDDの実装パターンとして、エンティティと値オブジェクトというものがあります。 ドメイン駆動一般に複雑な抽象論が多い中で、コードに近く一番イメージがつきやすいコード事例として出てくるため、ここだけは何となくわかるぞ！という方もいらっしゃるのではないでしょうか。 今日はこちらの概要とそれぞれの使い道について書きたいと思います。 先にざっくりイメージ図をお伝えすると、こういう図を使って解説します。 何の目的で作るのか？ ドメイン駆動設計は何を解決しようとしているのか こちらの記事で、ドメイン駆動設計のアプローチは以下の2ステップがあるということを書きました。 ドメインの問題を解決するための抽象的なモデルを作る. モデルをソフトウェア(コード)に落とし込む ※ ドメイン＝ソフトウェアを適用して問題解決しようとする領域 DDDでは、このStep2の モデルをコードで表現するためのパターン
ドメイン駆動設計 失敗したことと成功したこと
その時は最善の実装だと思っていたことでも、月日が立つことで、それは間違いだったと気づくことがあります。 5年という歳月はそれを気づかせるには十分な時間で、 DDDをやり始めた初期の頃に書かれたコードは良くディスられたりしています。 そのコードは何を失敗していたのか？そして、それは改善するために改善した事とは？ BIGLOBEにおける"今"のいいコードの書き方をできる限り具体的な事例を元に紹介します。
DCI Tokyo 1 - Lean Architecture by James Coplien - が開催されました（後編）
後半のセッションでは、「What the system is（共通性や可変性を分析する）」を説明しつつも、「What the system does」とは別のものとして切り分けることはできないという主張から、 DDD とリーンアーキテクチャとの比較、そしてパターンに関する議論が展開されました。 @remore が前半部分をまとめてくださっていまして、そこで出て来るいくつかの用語（Form, Structure, What the system is, What the system does）を前提として私のできる範囲で行いました。 なお当日のCoplien氏によるセッション内容は、許可を得た上でYouTubeにアップロードされていますので、より深くご覧になりたい方はこちらも併せてご参照下さい。 DCI Tokyo 1 - Lean Architecture by James Coplie
#teppeis_sushi でクライアントサイドDDDについて発表した
#teppeis_sushiというイベントで、Faao - ドメイン駆動設計で作るGitHub Issue Client -という話をしました。 Electronやブラウザなどで動くfaaoというGitHubクライアントを書いていてそれの技術的な話です。 クライアントサイドでDDDを取り入れた設計になっていて、その設計や規約の作り方やそれを守る方法についての話をしました。 azu/faao: Faao is a GitHub issue/pull-request client on Electron. Living Documentation by design, with Domain-Driven Design by Cyrille Martraire [PDF/iPad/Kindle]という無料から買える書籍では、ドキュメントとコードを同じ速度で成長させていくためにはドキュメントに対
PSR-7とPSR-15を使ったWebアプリケーション開発 - emonkak's Blog
はじめに PSR-7(HTTP Message)が承認されてからしばらく経ちますが、現在はこれを使った様々なライブラリ・フレームワークが登場しています。 これによって特定のライブラリ・フレームワークにロックインされずに、Webアプリケーションを実装できる道程が見えてきました。 しかし、PSR-7はあくまでHTTPメッセージのインターフェイスを提供するもので、リクエストを受け取ってレスポンスを返す流れを抽象化するものではありません。 これはHTTPミドルウェアと呼称されますが、そのインターフェイスはそれぞれの実装でまちまちです。 そこで、これを抽象化するPSR-15(HTTP Middleware)が提案されています。 ミドルウェアは大まかにダブルパスのミドルウェアと、シングパスのミドルウェアに分けることができます。 PSR-15は現在の所シングルパスのシグネチャを採用しています。 シングル
ドメイン駆動設計 実践のための原則を4つ考えてみた - HITORIGOTO
『エリック・エヴァンスのドメイン駆動設計』（以下DDD本と呼ぶ）の原著出版から十数年が経過した今、DDD本に書かれている内容は、吟味されアップデートされるべき時が来ている。このアップデートに盛り込みたい内容を、4つの原則という形で考えてみた。 なお、以下では「EvansのDDD本の内容」と「ドメイン駆動設計というコンセプト」は重なる部分があるにせよ、それぞれが指す対象は異なるものだとしている。この違いは本文中で触れるが、表記として「DDD本」は本を指し、「ドメイン駆動設計」はコンセプトの方を指すようにしている。 DDD本とドメイン駆動設計 DDD本では、ドメイン駆動設計というコンセプトが導入された。ドメイン駆動設計というコンセプトは、ソフトウェアエンジニアの一般教養といえるほど、今ではその価値が認められている。同様のアイデアは、EvansがDDD本を執筆した時代ですら、すでに先人たちが口に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
