タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
TypeScriptとドメイン駆動設計（DDD）を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
ドメイン駆動設計の正体
はじめに "ドメイン駆動設計は当たり前のことを言っているだけ" "ドメイン駆動設計はただのオブジェクト指向プログラミング" "ドメイン駆動設計はより良いアーキテクチャだ" "軽量DDDはアンチパターンだ" このようなドメイン駆動設計に関する言及を聞いたことがあるでしょうか？ ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。 おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。 そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。 ドメイン駆動設計の基本的概念について ドメイン駆動設計はEric Evansが出版した「Domain-Driven Design」という書籍がルーツになっています。 ドメイン駆動設計を一
社内LTにて、ドメイン駆動設計と依存性逆転の原則を布教しましたʕ◔ϖ◔ʔ はてなブックマークのコメントもどうぞ！ なお、ドメイン駆動設計を理解するためには、依存についても知る必要があります。 是非、依存関係と依存オブジェクト注入もご参照ください👍🏻
簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab
DDDではよく「モデリングが重要だ！」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。 そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めること これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。 そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めること これは、長期間開発しても機能拡張が容易であり
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
※追記あり。最後の追記は 2021/04/25 21:40頃※ タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。 この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく（易しく、ではない）ご指摘願いたい。 ※この記事では Web Application を前提とした話になっている。 DDDとは？https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88 DDD、ここがイケてる ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。 俗に言う「ビジネスサ
銀座Rails#26の登壇資料です https://ginza-rails.connpass.com/event/189892/
こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
過大評価されるDDD（ドメイン駆動設計）
この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計（DDD）は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア（TwitterやHacker Newsなど）で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし
巷で、顧客の課題を解決しつつ、より良いシステムを作るための設計手法として、ドメイン駆動設計（DDD）が話題になっていると思います。 このドメイン駆動設計について、どのように実践するか、実際に実践してみてどう感じたか、という話はよく出ていますが、作られたシステムがその後どのようになったのか、保守開発した結果どう感じたのかの話はあまり聞かないな、と思ったので、自分の経験から「実際のところどうなんだ」というところを振り返ってみようかな、と思い、今回の記事を書きました。 目次 私が保守開発しているシステム 5ヶ月の間にやったこと 保守開発していて感じたこと よかったこと 改修時に修正箇所が特定しやすかった テストコードが書きやすく安心して保守することができた 成長できたという実感があった 難しかったこと、学び ドメイン知識は次第に流出していく 定期的なメンテナンスが大事 最後に おまけ エンジニア
本記事はドメイン駆動設計(DDD) Advent Calendar 2021 25日目の記事です。 「もっとビジネス変化に耐えられる設計を目指したい」「ただデータをやりとりするだけなのに複雑化してしまうのを防ぎたい」 様々な動機からドメイン駆動設計に入門しようとする方がいると思います。 自分もエンジニアとして働きはじめて、「どうしてすぐに変更しにくくなってしまうのか」「より柔軟な設計にするにはどうすればよいか」と悩むことが多くなり、良い設計手法を探って出会ったのがドメイン駆動設計でした。 最初はドメイン駆動設計関連の本ばかりを読んでいたのですが、途中から「これってドメイン駆動設計というよりはオブジェクト指向の話では？」とオブジェクト指向に興味を移し、さらに「より変化に強いプロダクト開発するにはチームから変化させないとまずいのでは？」とアジャイル開発に興味が移りました。 本記事では、ドメイン
たのしいドメイン駆動設計: 序 / Enjoy domain driven design : ZYO
自分の開発に対する姿勢を根本的に変えたドメイン駆動設計(DDD)。ぜひみんなにもその面白さを知ってもらいたい！と思い社内向け資料を作成、さらにSpeakerDeckにて公開としました。 たのしんでご覧ください！ 関連note記事はこちら：https://note.com/jgc_parallel/n/n17db4b63affe
ドメイン駆動設計をわかりやすく - ドメインのモデル設計を手を動かしながら学ぼう｜ハイクラス転職・求人情報サイト AMBI（アンビ）
ドメイン駆動設計をわかりやすく - ドメインのモデル設計を手を動かしながら学ぼう ドメイン駆動設計（DDD）が近年関心を集めていますが、同時にこの設計思想は難しい、わかりにくい、という見方もあります。さまざまなプロジェクトでドメイン駆動設計を実践してきたかとじゅんさんが、サンプル課題をもとに、ユースケース分析、モデル設計といった基礎を解説します。 はじめまして、Chatworkでテックリードをしている、かとじゅん（ @j5ik2o ）です。 僕は2010年ころより、大小さまざまなプロジェクトでドメイン駆動設計、いわゆるDDD（Domain Driven Design）を導入した開発を実践してきました。ドメイン駆動設計を主題としたワークショップなども主宰していますが、最近では加速度的にこの設計思想への関心が高まっていると感じます。本稿では、なにかと分かりにくいドメイン駆動設計の基本を、架空の
ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 発売記念に、本書の1,2章の内容を中心にDDDの概要について解説する勉強会です。 Read less
10. 設計スタイルの違い 2019/8/31 10 関心 モジュール構造 ２０：８０ 入出力 ドメインロジック ビジネスルールに基づく計算と判断のロジック画面、テーブル、Web API トランザクションスクリプト 画面やデータに注目して、入出力手続きを構造化 値の種類に注目して、独自の型を定義 ドメインオブジェクトモデル 11. 設計スタイルの違い 2019/8/31 11 関心 モジュール構造 ２０：８０ 入出力 ドメインロジック ビジネスルールに基づく計算と判断のロジック画面、テーブル、Web API トランザクションスクリプト ドメインロジックの設計と実装が アプリケーション全体の構造を左右する 画面やデータに注目して、入出力手続きを構造化 値の種類に注目して、独自の型でロジックを構造化 入出力の設計と実装が アプリケーション全体の構造を左右する ドメインオブジェクトモデル
クラスをイミュータブルに設計するパターンの紹介 ・閉じた操作 ・withメソッド ・イベントリポジトリ＆集約ファクトリ
はじめに この記事はサービスを爆速で作ったり、ドメイン駆動設計の解説をするようなものではありません。 ドメイン駆動設計の勉強をしていて、手を動かす機会が足りないと感じていました。そこで、今の理解で実際に動くシステムをドメイン駆動で開発してみようと思いました。 本記事はその開発の過程や考えていたことを記録したものです。 「この人はこういう形に落とし込んだんだな～」くらいで見ていただけたらありがたいです。 作成するシステム 今回作るのはTODO管理システムです。 初回の開発では以下の機能を開発しました。 TODOのタイトルと詳細を登録できる 作成したTODOを検索できる 選択したTODOの詳細を確認、完了、削除ができる デモ デモなのでメールの確認はダミーです。新規登録をしたら画面に出るメール確認リンクを踏めば確認済みとなります。 その後右上のログインからログインしてください。 デモのデータベ
この記事では、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/fe5018ad772252621db406116ce62131478fb6b1/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20191202%2F20191202061944.png)
本書は、初めてDDDを学ぶ方、もしくは実際に着手して「難しい！！」と感じているエンジニアの方を対象とした、ドメイン駆動設計(以下、DDD)についての解説書です。 近年、ソフトウェアのレガシー化が社会的に問題になっていると言われています。 DDDはレガシー化への対策として非常に有用なものですが、日本語で出ている書籍「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」は非常に重厚かつ難解で、初学者が実用に到達するまでには長い時間と試行錯誤が必要なのが実情です。 そこで本書では、迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 また、その後にはレイヤーごとの個別のトピックについて、1章ずつ詳しく解説します。 ■本書の構成 本書は以下の構成になっています。 「第1章 DD
DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p
![DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/e19eb6aae8a33a9c7d58ab11012b9b1e4fd3dc14/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20210306%2F20210306230551.png)
本日(1月18日)発売された、Software Design誌 2023年2月号の第一特集で「ドメイン駆動設計入門」を書きました。 執筆の意図と記事の概要を簡単にまとめておきます。 Software Design 2023年2月号｜技術評論社 執筆の意図 特集のサブタイトルにある通り「設計力を磨きたい」読者が、ドメイン駆動設計の基礎を知ることで「設計の手法とアイデアの引き出し」を増やすことの役に立てればと思い執筆を引き受けました。 重視したこと 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える 全体像を伝えるための図や表を多めにした（ソースコードの例は少ない） 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』（以下『ドメイン駆動設計』）の説明を中心にした ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務
DDDにおける値オブジェクトの位置付け(モデルとコード事例あり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 最近、値オブジェクトに関して書かれているブログ記事を見ますが、 SNSなどにおいてDDDにおける値オブジェクトについて誤解されているような反応が見受けられました。 そこで、この記事では「DDDにおける値オブジェクトの位置付け」について解説し、具体的なモデル・コードを用いながら誤解を解いていきたいと思います。 なお、値オブジェクトに関する詳細な説明はここでは行いませんのでご了承下さい。 DDDの目的 まず最初に、DDDの目的について確認します。 DDDの目的は、モデリングを通じてソフトウェアの価値を大きくすることです。 これに関しては、こちらの記事で詳細に解説しているのでこちらをご覧ください。 ドメイン駆動設計は何を解決しようとしているのか - little hands' lab ここで大切なのは、モデルは一回のモデリングで完成形
![DDDにおける値オブジェクトの位置付け(モデルとコード事例あり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/d6ececc2d05edbf2c4b45bcb603bdecda34fde46/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20220815%2F20220815005816.png)
DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。 ドメインモデルの知識を対応するオブジェクトに書く 常に正しいインスタンスしか存在させない この2つを守ると、非常に保守性の高いコードにすることができます。 以下、詳細に解説します。 ドメインモデルの知識を対応するオブジェクトに書く ドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。 この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。 この基準はコード設計の指針として非常に役立ちます。 設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。 しかし、「ドメイン知識はドメイン層に書く」と
![DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/cf7c2977c5538fe370d1ff60a78958464a9e1f3f/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20220125%2F20220125074432.png)
ドメイン駆動設計(DDD)を整理
またクラスを利用していないため、オブジェクト指向の特性「継承」「カプセル化」「ポリモーフィズム」は利用していません。この部分が厳密なドメイン駆動設計(DDD)のニュアンスと異なるので「風味」という言葉を使っています。 全体概要と用語の整理 まず初めにドメイン駆動設計の全体の概要と出てくる用語について紹介します。 自分は言葉を理解しないとコードの理解に落とし込めなかったので詳しく解説をしていきます。 各用語の具体的な実装は後の章で紹介します。 すべての用語において理解しやすいように「ユーザー管理システムを実装する」例を用いて解説を入れています。(解説の都合で書籍とは異なる例を採用しています) ドメイン駆動設計とは ドメイン駆動設計はその名の通り、「ドメインの知識」に焦点をあてた設計方法 「ドメイン」とは、ソフトウェア開発におけるプログラムを適応する対象となる領域 ドメインについて ドメイン駆
こんにちは。最近Slackのカスタム絵文字作りにハマっている友野です。Holmesでサーバーサイドエンジニアをしています。 Holmesが提供するホームズクラウドは、今年8月にサービスローンチ3周年を迎えました！ これまでの支持に感謝し、これからも長く使ってもらえるようにプロダクト改善に取り組んでいます。そのひとつとして、ドメイン駆動設計（以下、DDDと表記します）適用に関する取り組みについてご紹介します。似たような状況や同じ課題を持つ誰かの一助になれば幸いです。 背景と現状 まずはじめたこと 戦略的モデリング そして、戦術的な設計 採用するパターン2つ ドメインモデルを反映したオブジェクトを置くパッケージの作成 既存テーブル構造に依存しないRepository+Adapterパターン ふりかえり まとめ 最後に 背景と現状 ホームズクラウドはPMF（Product Market Fit：
ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ - Qiita
この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
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/
![ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c7728c664ddd298cabc00615869a23f196ad5f90/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F2022-220117111455-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』が出版されます - Magnolia Tech
ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法 作者:Vlad KhononovオライリージャパンAmazon 2021年にO'Reilly Media, Inc.から出版された「Learning Domain-Driven Design」の待望の日本語訳『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』がついに出版されます。 www.oreilly.com 訳者は、増田 亨さん！！ 2020年代に、ドメイン駆動設計を学ぶための最初の入り口としてどの本を読めば良いかは、かなり悩ましい...というのはよく言われるのですが（元祖のエバンス本はさすがにだいぶ古くなってきたし、回りくどい表現も多いし...）、そんな時におすすめできる1冊です。 2021年に原著が出版された時に買ってざっと読んでいたのですが、パート1で戦略的DDD（
ドメイン駆動開発を浸透させるための新しい取り組み - SO Technologies 開発者ブログ
はじめまして、ライクル事業部 エンジニアの菊池@kichionです。 普段の業務では主にエンジニアチーム運営・運用の課題解決やビジネスサイドとのやり取りが多く、中長期目線でのアプローチを行っています。 エンジニアとして行っている技術選定や実装関連についてはZenn - kichionにも投稿していますので興味があればご覧になってください。 今回はライクル事業部として少しづつ取り入れ始めている「ドメイン駆動開発」に焦点を当てて見ます （ドメイン駆動に関わる内容については、端的ですがQiita - kichionにも投稿してますので気になったらご参照ください） ドメイン駆動開発（DDD） ドメイン ドメインモデリング 技術的要素 ドメイン駆動開発の目的 ドメイン駆動開発を浸透させるための取り組み ドメイン駆動開発 勉強会 ドメインオブジェクト整理会 今後やっていきたいこと 続・DDD勉強会 現
実践！モノリスからマイクロサービス！Event Stormingによるドメイン駆動設計から実装まで / AWS_Dev_Day_2023_E_3
AWS Dev Day 2023 Tokyo. E-3 「実践！モノリスからマイクロサービス！Event Stormingによるドメイン駆動設計から実装まで」 2023/06/23 at AWS Dev Day 2023 Tokyo
エヴァンス氏の『ドメイン駆動設計』の背景にある基本アイデアは何かという私の捉え方のメモ書き。 ドメイン駆動設計にはいろいろな側面がある。また書籍『ドメイン駆動設計』は体系だった設計方法論ではなく、設計の考え方とやり方を経験則として言語化してみた、と捉えている。 その経験則（100%ではないが多くの場合に役に立つ原則）の背景にあるエヴァンス氏の基本的な発想は次の５つに要約できると考えている。 ソフトウェアの複雑さは事業活動の複雑さに起因する 技術的な複雑さもあるが、ソフトウェアが複雑になるのは対象領域の複雑さが主たる理由という考え方。 業務アプリケーションであれば、事業活動の複雑さが業務アプリケーションの複雑さの原因と捉える。 ドメイン駆動設計は、この事業活動の複雑さに起因するソフトウェアの複雑さをうまく扱うための工夫、というのが私の捉え方。 ドメイン駆動設計という設計のアプローチを取り入れ
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ Yahoo!ショッピングクーポンチームの小倉です。 前回のフロントエンド技術刷新の話とは打って変わり、今回は2019年に行ったバックエンド技術刷新の話です。 刷新前のシステムはノンフレームワークPHPのモノリスでしたが、現在は主にJava/Spring Bootでマイクロサービス化しています。今回は、その中でもっとも仕様が複雑だったマイクロサービスにおいて、ドメイン駆動設計(Domain Driven Design:DDD)を実践した話をご紹介します。 ショッピングクーポンの自由度を知る みなさんは、ショッピングの商品が割引になるクーポンをご存じでしょうか？ 実は、クーポンには、ヤフーが予算をだして発行する「モールク
ドメイン知識とユースケースの違いは何か？[ドメイン駆動設計][DDD] - little hands' lab
DDDの文脈の中で、 「ドメイン知識とユースケース(≒アプリケーションの知識)は何が違うのか？」 という疑問がよく持たれます。 この記事ではその違いを説明し、DDDのコードにどう反映するかを書きます。 あるToDoアプリの仕様 事例として、ToDoアプリの話をします。 「仕様を決める」と言ったとき、以下のように箇条書きで決めることがあると思います。(Jiraのようなチケット管理システムのチケット詳細として書いたりしますよね) ユーザー登録、非活性化ができる メールアドレスは重複登録できない タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる タスクは3回までしか延期ができない 非活性化されていないユーザーにアサインができる タスクを完了、アサインするとタスクレポートが作成される これはいわゆる「ビジネスロジック」と呼ばれて、3層レイヤーのアーキテクチャではBusine
![ドメイン知識とユースケースの違いは何か？[ドメイン駆動設計][DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/5a33e295c3ac44927e7011b8da19b7195102699a/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20190726%2F20190726071431.png)
※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある３層構造です。何を見直して再設計するのか？それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く？本当に？ 開発対象のシステムはある情報の検索
Aws Dev Day2021 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)
フロントエンドエンジニアの友人と“型”で話がすれ違った原因 YUMEMI.grow合同LT会in横浜 @Kaito-Dogi
システム構築にかかるコスト・期間は20年単位で倍々に増加している。これは「2025年の崖」で示されているレガシーシステムの問題も大きいが、ウォーターフォールモデルで専門家による分業制をとっているシステム開発生産ラインのありようも看過できない。一方、アジャイル開発によるコスト削減や開発期間短縮の効果について、大規模な金融系システムでの実例はまだ少ない。さらに、昨今のマイクロサービスを実現するための設計手法も確立できてはいないと考える。 今回、筆者らチームは「ドメイン駆動設計」を活用し、システム構築コスト・期間を大幅に削減し、かつマイクロサービスに適合するシステム開発の可能性についてのPoCを実施した。
オブジェクト指向プログラミングとドメイン駆動設計を学ぶのに適切な書籍とおすすめの読む順番 - Qiita
オブジェクト指向プログラミングが学べる書籍たち もし私が今から最初から学ぶならこの順番でこの本読むだろうという紹介です。 新人プログラマの方々は右も左も分からないというところからスタートとなるため、オブジェクト指向プログラミングを学ぶときに何から学べば良いか全くわからないという状況かと思います。 オブジェクト指向プログラミングを学んでいると自然と出会うドメイン駆動設計についても同様です。 そうした方々が書籍から学ぼうとした場合に、少しでも効率良く進められる順番を示してあげられれば良いなと思って紹介します。ただし、各書籍についての詳細な説明は書いていません（というか結構忘れててかけない）…。 なお、前提言語はJavaで言語構文にも十分詳しいことが大前提です。 以降、オブジェクト指向プログラミングはOOPと略します。 現場で役立つシステム設計の原則 OOPらしさの雰囲気がわかります 入り口に最
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
🏗️ ドメイン駆動設計と依存性逆転の原則
DDD(ドメイン駆動設計)、理念に大賛成、実装に大反対。
Railsで考えるドメイン駆動設計のコアドメイン
ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
ドメイン駆動設計（DDD）で開発されたシステムを5ヶ月保守開発した感想・学び - Qiita
ドメイン駆動設計からオブジェクト指向、そしてアジャイル開発まで。関連書籍練り歩きのススメ
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計という設計スタイル
ドメイン駆動設計とイミュータブルなクラス設計
とにかくドメイン駆動設計を実践してみる試み ～TODO管理システム編～
CQRS実践入門 [ドメイン駆動設計] - little hands' lab
ドメイン駆動設計 モデリング/実装ガイド - little-hands - BOOTH
『ドメイン駆動設計』の解説記事を書きました - ソフトウェア設計を考える
プロダクトにドメイン駆動設計を適用するためにはじめたこと - ContractS開発者ブログ
『ドメイン駆動設計』の５つの基本アイデア - ソフトウェア設計を考える
ドメイン駆動設計で保守性をあげたリニューアル事例 〜 ショッピングクーポンの設計紹介
大失敗した設計、そしてドメイン駆動設計の基本に立ち返る – 福地春喜のブログ
ドメイン駆動設計に１５年取り組んでわかったこと
形から入ったドメイン駆動設計によるゲーム開発の光と闇
ドメイン駆動設計によるシステム開発 | 知的資産創造 | 野村総合研究所(NRI)
ren.nm.bex.jp
www.all-nationz.com
blog.goo.ne.jp/gokudo0339
www.yomiuri.co.jp
toushi.xn--w8j1at4m.tokyo
aistageup777.com