この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか？ 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか？は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか？」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。
マイクロサービスの再考: タダ飯なんてものはない
どうも、株式会社プラハCEO兼エンジニアの松原です。 先日かとじゅんさんがツイートで紹介していたマイクロサービスに関する論文を読むついでに、適度に意訳した内容を音声入力してみました。ついでに意訳レベルなので翻訳の質は保証できないのですが、もし内容を読んでみて少しでも興味を持てた場合は実際の論文にも目を通してみると良いかもしれません。 論文のリンク: 「これ日本語でなんて言うの？」って分からなかった部分も多々あったのでより適切な単語があったら教えてほしい...! 導入 マイクロサービスには様々なプラクティスや技術を用いて以下のメリットを目指す 素早いデリバリー 高いスケーラビリティ 自律性 しかし実際にこの業界で実装されるマイクロサービスは採用するプラクティスや効果に大きな差があるため、オンラインサーベイ(51回答)と経験豊富なマイクロサービス実践者14名にインタビューを行った。 わかったこ
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をそのまま「商品クラス」と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。
DDDとORMのEntityを混同しないための考え方
２つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んでいます。例えば PHP のDoctrineや TypeScript のTypeORMなどがそうです。 そういった ORM を採用したプロジェクトで DDD に取り組むとき困るのが用語の衝突です。ORM の Entity は RDB のための定義を含むため当然 DDD の Entity とは異なるのですが、なにぶん同じ名前なので混同してしまいがちです。 本記事では両者を混同せず扱うための考え方をまとめます。 Entity の定義 まずは定義から確認します。 DDD での定義 エヴァンス本の日本語訳から引用します。 主として同一性によって定義されるオブジェクトはエンティティと呼ばれる Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edi
PoEAA を通して DDD の半分を理解する マーティン・ファウラーの PoEAA を読んでから、DDD のことを考え続けている。今まで DDD の話題はあえて避けてきた。分厚く難解な書籍、増えるコード量、教祖とその信徒たち（MV）、全てをその視点から解釈しようとする試み、少しでも間違えたら求められる自己批判、無知な者に対する SNS 上のオルグ、いつまでも出てこない総括、それでも信じるものは救われる。「一匹の亡霊がIT界隈を徘徊してる。DDDという亡霊が...」 まあ早まらないでほしい。何も DDD こき下ろそうというわけではない。自分の実力不足が主な原因と思い、深入りする前から「わからないもの」と決めつけていた DDD は、PoEAA というライトに照らされてその姿を私の前に姿を表し始めた。それは亡霊ではなく、確固たる手触りのある実体（Entity）だったのである。 PoEAA は
ドメイン駆動設計(DDD)を整理
またクラスを利用していないため、オブジェクト指向の特性「継承」「カプセル化」「ポリモーフィズム」は利用していません。この部分が厳密なドメイン駆動設計(DDD)のニュアンスと異なるので「風味」という言葉を使っています。 全体概要と用語の整理 まず初めにドメイン駆動設計の全体の概要と出てくる用語について紹介します。 自分は言葉を理解しないとコードの理解に落とし込めなかったので詳しく解説をしていきます。 各用語の具体的な実装は後の章で紹介します。 すべての用語において理解しやすいように「ユーザー管理システムを実装する」例を用いて解説を入れています。(解説の都合で書籍とは異なる例を採用しています) ドメイン駆動設計とは ドメイン駆動設計はその名の通り、「ドメインの知識」に焦点をあてた設計方法 「ドメイン」とは、ソフトウェア開発におけるプログラムを適応する対象となる領域 ドメインについて ドメイン駆
開発メンバーが選ぶ、おすすめの技術書【2020年度】 - RAKUS Developers Blog | ラクス エンジニアブログ
技術広報のsyoneshinです。 今回は当社の開発組織メンバー達に 読んでよかった 自身が影響を受けた 他者にも読んでほしいと思った という観点で 『おすすめの技術書』とおすすめポイントを聞きました。 質問：皆さんの「おススメの技術書」 を教えてください。 【目次】 おすすめの技術書ランキング 『リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』 『マスタリングTCP/IP 入門編』 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』 『達人プログラマー 職人から名匠への道』 『Webを支える技術』 『SQLアンチパターン』 『Java言語で学ぶデザインパターン入門』 『はじめて学ぶ ソフトウェアのテスト技法』 『UNIXという考え方―その設計思想と哲学』 『Effective Jav
はじめてScalaに触れたとき、変数宣言(var)と値宣言（val)を使い分ける言語仕様に、なるほどなあ、と思った。簡単に言えば、変数(var)は再代入できて、値（val)は再代入できない。 プログラミングのスタイルとして、var宣言は命令的なプログラミング、val宣言は宣言的なプログラミングになる。どちらのプログラミングスタイルで書いているかを、varとvalで明示できるわけだ。 Javaだと言語の基本の仕組みはすべてが変数。final宣言をすることで再代入をコンパイルエラーにすることはできる。Javaは、C言語やC++などの命令的なプログラミングの系譜の言語なのですべて変数(variable)というのは、とうぜんの言語仕様だった。 命令的なスタイルから宣言的なスタイルに 命令的なプログラミングでは変数(variable)を使う。宣言的なプログラミングでは値(value)を使う。 再代入
みなさん、こんにちは！プロダクト開発部の吉川（@yoshiyu0922）です。 現在、JMDCが保有している医療ビッグデータを活用して生活者や医療に新しい価値を提供する新規プロダクト開発チームのバックエンドを担当しております。 以前に新規プロダクト開発で採用している技術や設計についてこちらの記事で紹介しましたが、Go x GraphQL x DDDでプロダクト開発をしています。今回はプロダクトの開発が一区切りしてこれからリリースするということで、開発してみて良かったことやこうすれば良かったことを振り返りをしました。振り返りの内容は主にDDDに関することです。 DDDとは DDDとは「Domain-Driven Design」の略語でドメイン駆動設計と呼ばれるソフトウェア開発手法の一つです。問題を解決しようとする領域（ドメイン）をモデリングによってソフトウェアの設計や実装に反映させることで、
こんにちは。最近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)
エヴァンス氏の『ドメイン駆動設計』の背景にある基本アイデアは何かという私の捉え方のメモ書き。 ドメイン駆動設計にはいろいろな側面がある。また書籍『ドメイン駆動設計』は体系だった設計方法論ではなく、設計の考え方とやり方を経験則として言語化してみた、と捉えている。 その経験則（100%ではないが多くの場合に役に立つ原則）の背景にあるエヴァンス氏の基本的な発想は次の５つに要約できると考えている。 ソフトウェアの複雑さは事業活動の複雑さに起因する 技術的な複雑さもあるが、ソフトウェアが複雑になるのは対象領域の複雑さが主たる理由という考え方。 業務アプリケーションであれば、事業活動の複雑さが業務アプリケーションの複雑さの原因と捉える。 ドメイン駆動設計は、この事業活動の複雑さに起因するソフトウェアの複雑さをうまく扱うための工夫、というのが私の捉え方。 ドメイン駆動設計という設計のアプローチを取り入れ
React Hooks + Redux Hooks + TypeScript で SPA を構築する（追記あり） - 30歳からのプログラミング
2020/05/31 追記 勉強や経験を重ねた結果、この記事を執筆した時より知識が増え、コードの書き方にも変化があります。 サンプルアプリも同様で、以下のプロダクトのコードのほうが、今の自分の考えが反映されていると思います。 github.com 追記終わり 2019/07/14 追記 ディスカウント後の価格みたいな導出項目はselector (reselect)を使うとよいのでは https://redux.js.org/recipes/computing-derived-data - YonmanHasse のブックマーク / はてなブックマーク というコメントを頂き、確かに便利そうだったので導入した。 それに合わせてこの記事の内容もアップデートした。 追記終わり タイトルに書いた組み合わせで SPA を作るときにどのような設計にするのか、現時点での考えを記録しておく。 チュートリアル
ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により
ヤフー株式会社は、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 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)
この記事について この記事は2020年3月30日に BPStudy#151〜オブジェクト指向、モデリング、設計 LT大会[リモート開催]という勉強会でDDD時代に考えたいICONIXプロセスというスライドを発表させて頂いたのですが、発表時間の都合上説明できなかった部分をもう一歩踏み込んで具体的なやり方を紹介する為にまとめたものです。 スライドをご覧になって頂いた上で読んで頂くとより前後関係がわかりやすくなりますが、スライドを見ていなくてもこの記事から読んで頂いても問題ありません。 序 みなさんDDDは好きですか？ 筆者は大好きです。 DDDとは簡潔に説明すると**「ドメインに詳しい人と一緒に育てたモデルをそのままコードに落としむ」**という設計手法です。 モデルとコードが対応しているからモデルの育成と共にコードを育てられる。そしてそのモデルはドメインに詳しい人と共に育てる。 凄く良さそうで
システム構築にかかるコスト・期間は20年単位で倍々に増加している。これは「2025年の崖」で示されているレガシーシステムの問題も大きいが、ウォーターフォールモデルで専門家による分業制をとっているシステム開発生産ラインのありようも看過できない。一方、アジャイル開発によるコスト削減や開発期間短縮の効果について、大規模な金融系システムでの実例はまだ少ない。さらに、昨今のマイクロサービスを実現するための設計手法も確立できてはいないと考える。 今回、筆者らチームは「ドメイン駆動設計」を活用し、システム構築コスト・期間を大幅に削減し、かつマイクロサービスに適合するシステム開発の可能性についてのPoCを実施した。
DDDを学習・実践において多く見受けられる混乱と、それに対する現時点での自分の回答
オブジェクト指向プログラミングとドメイン駆動設計を学ぶのに適切な書籍とおすすめの読む順番 - Qiita
オブジェクト指向プログラミングが学べる書籍たち もし私が今から最初から学ぶならこの順番でこの本読むだろうという紹介です。 新人プログラマの方々は右も左も分からないというところからスタートとなるため、オブジェクト指向プログラミングを学ぶときに何から学べば良いか全くわからないという状況かと思います。 オブジェクト指向プログラミングを学んでいると自然と出会うドメイン駆動設計についても同様です。 そうした方々が書籍から学ぼうとした場合に、少しでも効率良く進められる順番を示してあげられれば良いなと思って紹介します。ただし、各書籍についての詳細な説明は書いていません（というか結構忘れててかけない）…。 なお、前提言語はJavaで言語構文にも十分詳しいことが大前提です。 以降、オブジェクト指向プログラミングはOOPと略します。 現場で役立つシステム設計の原則 OOPらしさの雰囲気がわかります 入り口に最
最近、ドメイン駆動設計(以下DDD)とかそのあたりを読みこんでいる人から、DDD本の読み方を教えてもらいました。ここではDDD本はエリック・エヴァンスのドメイン駆動設計の方を参照しました。 @katzchang さんから教わったのは「DDDはパターンランゲージの形式を意識してるよ」ということでした。ただし、きちんとしたパターンランゲージの形式になっておらず、記述が著者のものになってるので、読者は注意して読む必要があるのかもとのことです。 @ryoaitaさんから教わったのは「DDDはエンタープライズアプリケーションアーキテクチャパターン(以下PofEAA)を下敷きにしている本だよ」ということでした。 DDDももう時代的にはかなり古い本です。自分で読んだ限りは全然好きになれなくて、でもきっと何かあるはずだと3-4冊読んでみましたが感想は変わらずでした。ユビキタス言語も「当たり前のものを先頭に
業務で扱う(最小)単位でデータとロジックをひとまとめにして整理する技法 ドメインモデルが実現する世界 どこに何のロジックが書いてあるか、(ソースを見るだけで)わかる 改修しやすいプログラム ドメインモデルで解決したい問題 どこに何のロジックが書いてあるかわからない問題 - わからないから適当に書く→適当に書くからわからない → わからないから・・・ - ある修正をしようと思っても、どこまでが影響範囲かわからない - 使用している箇所全grepして調査 - 同じような処理、分岐が重複してしまう これを解決したい。これだけを考える。 なぜ(今までのシステムは)改修は難しいのか 機能クラスと、データクラスをわけてしまうから そのデータクラスを呼べる箇所 = 業務ロジックがかけてしまう どこになにが書いてあるかわからなくなる 共通クラス、Utilクラスを作ってしまうから 誰でも呼べる = そのクラ
1995年まで：イノベータとアーリーアダプターの時代； 1995-2005 ： オブジェクト指向ブームと混乱の始まり； 2005-2015 ： さらなる混乱と収束の兆し； 2015- ; 現在の状況とこれからの２０年Read less
エンジニア歴1年の僕がドメイン駆動設計(DDD)を参考にLaravelのプロジェクトをフルリニューアルした話 - Hajimari Tech Blog| 株式会社Hajimari
こんにちは！ はじめまして！ 2020年7月からPIECE事業部でエンジニアをさせてもらっています。 野澤です。 今回、PIECEというサービスのリニューアルを担当させてもらったのでその時のことについて書きたいと思います！ まだ若輩者なので至らない点が多々あると思いますが フルリニューアルってどんな事したんだろう〜？ Hajimariのエンジニアはどんな仕事をしてるんだろう〜？ って思った人はぜひ読んで見てください！ ※ドメイン駆動設計の説明も書いたのですがボリュームが多くなってしまいました… ドメイン駆動設計について概要知りたいという方は是非読んでみてください。 クリーンアーキテクチャの説明やモデリングのやり方などは説明していません。 ご了承ください。 PIECEリファクタリングプロジェクトの概要 PIECEとはどのようなサービスなのか リニューアルの目的 リニューアル施策 ドメイン駆動
PlantUMLでドメイン駆動設計のモデリングを実装する（Nizi Project編） - ContractS開発者ブログ
こんにちは！株式会社Holmesでエンジニアをしている平田です。 Holmesでは、現在、プロダクト開発にドメイン駆動設計を取り入れようと、社内で勉強会の開催や各メンバーが勉強したことを共有しあったりしています。 ドメイン駆動設計に取り組むにあたって、大切なことのことの一つにより良いモデルを作成する、モデリングがあります。 今回はそんなモデリングをPlantUMLで行う方法について、一例をご紹介できればと思います。 ※本記事のモデリング手法は以下の書籍を参考に行なっております。 PlantUMLとは なぜPlantUMLを用いるのか ユースケース図 全体像 @startuml,@enduml actors usecases rectangle ドメインモデル図 全体像 packages objects notes direction relations label 振り返り 最後に Pla
コードの品質を上げることを目的として導入されることも多いドメイン駆動設計（DDD）。しかし、その本質は「モデリングでソフトウェアの価値を高める」ことです。そのためには、アプリケーション層とドメイン層を区別し、どの層に何を実装するのかを決めるのが重要です。DDDの本質、そしてモデリングから実装までの考え方を松岡幸一郎氏が語ります。講演資料はこちら 「モデル」を定義する 松岡幸一郎氏：では、モデルとは何でしょうか。いろんな人がいろんなことを言うんですね。DBA（データベース管理者）のような人だと「モデルとはDBのテーブルのこと」だと言ったり、サーバサードエンジニアの人だと「テーブルに対応したオブジェクトのこと」と言ったり、機械学習エンジニアの人は「数式のこと」をモデルと言ったりします。 モデルを作ることをモデリングと呼ぶわけですが、モデリングで価値を出していこうと言っているのに、モデルの定義が
【2020年版】ドメイン駆動設計（DDD）初学者へ贈るおすすめ書籍 - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。west-cです。 携わっている新規サービスにてドメイン駆動設計（以下、DDD）を取り入れた開発を行っていることから、去年の秋頃からDDDの学習をはじめました。 今回は、私が学習にあたり読んだおすすめ書籍を紹介します。 目次 目次 ドメイン駆動設計とは おすすめ書籍 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 ドメイン駆動設計 モデリング/実装ガイド ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 実践ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 おわりに ドメイン駆動設計とは 本題へ入る前に、「そもそもDDDって何？」という方へ3行でとてもざっくりと説明します。 DDDとは、ソフトウェアで問題解決しようとする領域（ドメ
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか - little hands' lab
Object-Oriented Conference 2020で登壇させていただきました。 その際の発表資料です。 発表資料 DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか from Koichiro Matsuoka www.slideshare.net 本章の内容は技術書典8(2020/3/1)で頒布予定の「ドメイン駆動設計 モデリング/実装ガイド」の1,2章の内容になります。 全部で11章仕立てです、興味お持ちいただけたらお買い求めください。 受け取りは技術書典以降になりますが、それでもよろしければboothで予約可能です。 little-hands.booth.pm また、実践にあたって頻出の疑問に対してトピックごとに詳しく解説した書籍もあります。 重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具
こんにちは！エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでバックエンドエンジニアをしている椿（@mikr29028944）です。 Gaudiyは、まだエンジニア10名、デザイナー2名ほどの開発チームですが、今年の6月からDDDと呼ばれるドメイン駆動設計を開発に取り入れました。 DDDとは、一言で言うとドメインエキスパートと呼ばれる担当業務やシステム設計に最も詳しい人と、エンジニアが共創してソフトウェアを開発する手法です。 今回は、DDDを実践する中での気づきや学び、躓きやすいポイントをどのように乗り越えてきたかについて、ご紹介してみたいと思います。 DDDを検討しているチームや、導入して間もないチームのご参考になれば幸いです！ 1.なぜDDDを導入したのか 2.GaudiyではどのようにDDDを取り入れているか 3.DDDの実践で生じた課題と乗り越え方 3-1.チ
「DDDのモデリングとは何なのか、 そしてどうコードに落とすのか」資料 / Q&A - little hands' lab
Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！ コラボカンファレンス に登壇させていただいたのでで、その際の資料です。 また、当日sli.doでたくさんのご質問をいただいたので、まとめてお答えします。 発表資料 DDDのモデリングとは何なのか、 そしてどうコードに落とすのか from Koichiro Matsuoka www.slideshare.net もっと詳しく知りたい方は この発表資料の内容を、さらに詳しく解説した書籍を出しました！ little-hands.booth.pm 初めてDDDを学ぶ方、もしくは実際に着手して難しさにぶつかっている方向けの書籍になっています。 迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 この本の「第2章
あらゆる場面でデザインを駆使するための技術 / Techniques for Applying Design in Any Situation
この記事は 弁護士ドットコム Advent Calendar 2020 19日目の記事です。12月19日の午前2時を過ぎて苛立ちがドアを叩くころです。 今年は上野学さんの単著『オブジェクト指向UIデザイン 使いやすいソフトウェアの原理』が発売され、OOUIという言葉が盛り上がっていますね。昨日のアドベントカレンダーの記事を書いた @shirauix さんともOOUIの話で盛り上がり、彼が主催で社内読書会も行われました。 さて、世間的にも社内的にもOOUIが盛り上がって読書会も開催されるなか、わたしは社内でひっそりと「タスクベースUI」の勉強会をやったのでした。 タスクベースUI？ 「タスクベースUI」という言葉は、先程の上野さんが盛んに言及することで最近有名になった言葉な気がします。 『オブジェクト指向UIデザイン』から引用します。 GUIのようにオブジェクトを起点として設計された操作モデ
DDDのエンティティはイミュータブルな実装にしてもいいの？(サンプルコード有り)[ドメイン駆動設計 / DDD] - little hands' lab
本記事はドメイン駆動設計（ＤＤＤ） Advent Calendar 2021の13日目の記事です。 エンティティとイミュータブル性 オブジェクトをイミュータブル、つまり内部状態を変えない実装にすることで可読性やマルチスレッド対応性が向上することがあります。 エンティティはモデリング上の定義はミュータブルなものですが、実装方法をイミュータブルにすることは可能です。 (DDDでは、エンティティはミュータブルもしくはイミュータブル、値オブジェクトは必ずイミュータブルという定義です。詳しくはこちら) DDD基礎解説：Entity、ValueObjectってなんなんだ - little hands' lab 本記事ではエンティティをイミュータブルな実装にするサンプルコードと合わせて、イミュータブルにした場合の旨みを感じられるコードを紹介します。 イミュータブルなエンティティ実装の例 エンティティをイ
![DDDのエンティティはイミュータブルな実装にしてもいいの？(サンプルコード有り)[ドメイン駆動設計 / DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/2b44a04ab53f865fdbd22ebaaedd541c0abb3877/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20211213%2F20211213073035.png)
わかりやすくて最高だった「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」レビュー | DevelopersIO
わかりやすくて最高だった「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」レビュー 「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」を読んだところ、とても良かったのでレビューしたいと思います。 私の状況 まずこの本を読む前の私がどの程度ドメイン駆動設計について理解していたかご紹介します。 以前同僚が書いてくれたサンプルコードを手本にレイヤードアーキテクチャみたいなTypeScriptのLambda関数を書いている 「Service」とか「Repository」とかの単語を命名に使っているが、使い方あってるのか自信ない、というか意味をよくわかっていない 実装中「この構成でええんか？」と何度も思い悩む 時間かかるくらいなら雑にさっさと書いてしまったほうが良いのでは、と思うこともある。けどちゃんとしたコードを書きたいんや。 こういうのを読んで、テストしや
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 の17日目の記事です https://qiita.com/advent-calendar/2023/loglassこんにちは。ログラスでエンジニアをしております、南部です。 ログラスでは、当アドベントカレンダーの5日目の記事で紹介されていますように、「DDDもスクラムも当たり前」な開発組織が形成されています。 私は、今年の9月からログラスに入社していますので、上記の記事で紹介されているログラスのDNAを受け継ぐ側に当たるかと思います。 そしてちょうど直近で、DDDの文脈においてこのDNAの価値を感じる機会がありました。 実は、前職でもDDDっぽいコードを取り入れたりはしていたのですが、それによって特にメリットは得られておらず悩んでいました。 結論、原因は私の不勉強でDDDの価値を出せる条件となって
19/07/24開催の「持続可能なプロダクト開発への取り組み ～メドピアとクラウドワークスの事例公開～」における、クラウドワークス側の登壇資料です。 https://connpass.com/event/136791/
「現場で役立つシステム設計の原則」と「レガシーコードからの脱却」を読んでUnity開発のテスト自動化への危機感UP - kidoOooOoooOOom
「現場で役立つシステム設計の原則」を読み終わって、今は「レガシーコードからの脱却」を読んでいる途中。 先日のEOF2019であったt_wadaさんの「質とスピード」、ryuzeeさんの「レガシーコードからの脱却」の資料も合わせて読むと理解が深まってくる。 speakerdeck.com slide.meguro.ryuzee.com 内部品質であるソフトウェアの保守性を高めること t_wadaさんの「質とスピード」スライドより t_wadaさんの「質とスピード」スライドより 最初から作るべきものが正しく予測できて、それを一発本番の開発フローで正しく作ることが「幻想であること」がもう分かってきたので、最近はアジャイル開発がキャズムを超えてきている。 当てになりにくい「予測」よりも「対応」（=変更容易性=適応性）を高めるプラクティスが重要になってきていて、テスト自動化やドメイン駆動、モブプロな
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターンの紹介」
関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita
DDDの正体は実装パターンとモデリングの組み合わせ - パンダのプログラミングブログ
変数(variable)と値(value) - ソフトウェア設計を考える
DDDでプロダクト開発をしたので振り返ってみた - JMDC TECH BLOG
プロダクトにドメイン駆動設計を適用するためにはじめたこと - ContractS開発者ブログ
『ドメイン駆動設計』の５つの基本アイデア - ソフトウェア設計を考える
ソフトウェアのもっとも重要な品質は発展性 - ソフトウェア設計を考える
ドメイン駆動設計で保守性をあげたリニューアル事例 〜 ショッピングクーポンの設計紹介
大失敗した設計、そしてドメイン駆動設計の基本に立ち返る – 福地春喜のブログ
ドメイン駆動設計に１５年取り組んでわかったこと
明日から使えるDDDのためのユースケース駆動開発（ICONIXプロセス） - Qiita
ドメイン駆動設計によるシステム開発 | 知的資産創造 | 野村総合研究所(NRI)
何がDDDをDDDにするのか / what make DDD to DDD ?
ドメイン駆動設計の源流のPofEAAを読んでみる | フューチャー技術ブログ
ドメインモデルとは(「現場で役立つシステム設計の原則」より) - Qiita
オブジェクト指向プログラミングの現在・過去・未来
ドメイン駆動設計における「良いモデル」と「悪いモデル」とは
DDDを試行錯誤しながら実践するチームの学びをまとめてみた - Gaudiy Tech Blog
IBM Dojo 挫折しないドメイン駆動設計 20210825pm
タスクベースUIとCQRS - Qiita
「DDDもスクラムも当たり前」な開発者組織に入って気付かされたDDDの価値を出すための条件｜南部豪
クラウドワークス プロダクトの持続的開発のためのリファクタリング実践アプローチ