DDD基礎解説：エンティティ、値オブジェクトってなんなんだ - little hands' lab
はじめに DDDの実装パターンとして、エンティティと値オブジェクトというものがあります。 ドメイン駆動一般に複雑な抽象論が多い中で、コードに近く一番イメージがつきやすいコード事例として出てくるため、ここだけは何となくわかるぞ！という方もいらっしゃるのではないでしょうか。 今日はこちらの概要とそれぞれの使い道について書きたいと思います。 先にざっくりイメージ図をお伝えすると、こういう図を使って解説します。 何の目的で作るのか？ ドメイン駆動設計は何を解決しようとしているのか こちらの記事で、ドメイン駆動設計のアプローチは以下の2ステップがあるということを書きました。 ドメインの問題を解決するための抽象的なモデルを作る. モデルをソフトウェア(コード)に落とし込む ※ ドメイン＝ソフトウェアを適用して問題解決しようとする領域 DDDでは、このStep2の モデルをコードで表現するためのパターン
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
チュートリアルでDDD体験: ドメインモデルの成長を紹介 - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
プロダクト技術本部の川口です。 3年間、ビッグローブ光といった固定回線のインフラ部門に所属していましたが、今年の4月に BIGLOBE の基幹システムのリニューアルを推進していく部署に異動することになりました。 所属するチームでは、ドメイン駆動設計（DDD）で開発しています。 チームにジョインすると開発チュートリアルをやることになっており、そこで IntelliJ や Spring Boot での開発の仕方を学んだり、チュートリアルを通して DDD を学んだりします。 今回は、DDD のチュートリアルで実際に作成したドメインモデルがどういう風に成長していったかについて紹介します。 勤怠管理アプリ チュートリアル 初期ドメインモデル 中期ドメインモデル 後期ドメインモデル 学んだこと、感想 勤怠管理アプリ チュートリアル お題は GitHub のパブリックリポジトリに公開されています。 ht
DDDでの要件定義〜実装までの流れについて解説します
本記事では、ソフトウェア開発手法の一つであるDDD（domain-driven design）を使って要件定義〜実装を行う際のプロセスやポイントについてまとめていきます。 （書籍「ドメイン駆動設計モデリング/実装ガイド」の内容を大いに参考にさせていただいていますが、独自の内容・考察も記載しているつもりです。） DDD とは？ DDD（domain-driven design）は日本語に訳すとドメイン駆動設計で、ソフトウェア開発手法の一つです。 ドメイン駆動という言葉から、ドメインというものが重要そうだということは伝わってくると思いますが、そもそもドメインという言葉が抽象的でわかりにくいですよね。 ドメインは直訳すると「領域」ですが、DDD で指している「領域」とは「ソフトウェアで問題解決しようとする対象領域」です。 そして、① ドメインについての理解を深めてモデルを作成し（DDD では、後
風刺動画「一枚岩モデル」で考える、DDDの境界付けられたコンテキスト / huge model vs bc
AWS Dev Day 2022 Japanの登壇に用いた資料です https://aws.amazon.com/jp/events/devday/japan/?aws-dev-day-2022-japan-cards.sort-by=item.additionalFields.sortOrder&aws-dev-day-2022-japan-cards.sort-order=asc&awsf.aws-dev-day-2022-japan-filter-session-category2=*all&awsf.aws-dev-day-2022-japan-filter-track=track%23track-a&awsf.aws-dev-day-2022-japan-filter-dev-type=*all&awsf.aws-dev-day-2022-japan-filter-dev-sub
ValueObjectという考え方 - Qiita
以前、DDD（ドメイン駆動開発）を経験した流れでいくつかのことを学びました その中でDDDの神髄を垣間見たのでかいつまんで紹介できればと思います 記事のターゲット DDDを学び始めた人 値オブジェクト・ValueObjectとはなにか、その片鱗を知りたい人 Value Objectとは 値オブジェクトとしてエリック本(青本)では紹介していますね Value Objectの特徴 特徴として以下のような内容があります 一意性を持たない 計測／定量化／説明を責務とする イミュータブルオブジェクト 交換可能 ふるまいに副作用がない 一意性を持たない オブジェクト毎に hogehoge_id のような一意性を表現するプロパティを含まず、一意性がない特徴です 逆にIDを持つようなオブジェクトは「Entity」といいます この特徴の意味するところはオブジェクトをプリミティブライクに扱えることだと考えられ
最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ
DDD is dead. God is in Twitter #scrumsapporo
Scrum Fest Sapporo 2021でプレゼンしました。 私達の愛したDDDを取り戻すための苦悩と挑戦について紹介します。本作品はマリリン・マンソン Rock is dead オマージュ作品となっております。 DDDはその構造上、デザイン思考やリーンスタートアップやディスカバリーといったものを考慮しておらず、デリバリーフェーズを意識した手法になっているのですけど、これはチーム開発のボトルネックを生み出す原因になりがちではないでしょうか？ デリバリーにおいてはドメインを語れる人がいく人かおり、それをベースにそこそこの規模のシステム設計やアプリケーション設計をしていく。その過程でDDDを実践したという経験がつくわけですが、その人に対して、新規事業であったり、若々しい状態の事業のサポートをお願いすると、劣化したDDDのような設計をベースに進めつつ、現場のプログラマーを説得する行為に走る
ドメイン駆動開発を浸透させるための新しい取り組み - SO Technologies 開発者ブログ
はじめまして、ライクル事業部 エンジニアの菊池@kichionです。 普段の業務では主にエンジニアチーム運営・運用の課題解決やビジネスサイドとのやり取りが多く、中長期目線でのアプローチを行っています。 エンジニアとして行っている技術選定や実装関連についてはZenn - kichionにも投稿していますので興味があればご覧になってください。 今回はライクル事業部として少しづつ取り入れ始めている「ドメイン駆動開発」に焦点を当てて見ます （ドメイン駆動に関わる内容については、端的ですがQiita - kichionにも投稿してますので気になったらご参照ください） ドメイン駆動開発（DDD） ドメイン ドメインモデリング 技術的要素 ドメイン駆動開発の目的 ドメイン駆動開発を浸透させるための取り組み ドメイン駆動開発 勉強会 ドメインオブジェクト整理会 今後やっていきたいこと 続・DDD勉強会 現
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
【Go】厳密なClean Architectureとその妥協案 - Qiita
Clean Architectureとは Clean Architecture(クリーンアーキテクチャ)とは，レイヤに内側と外側の関係性を持たせるアーキテクチャである． 「外側のレイヤは内側のレイヤだけに依存する」というルールを守ることによって，アプリケーションから技術を分離することが目的である． 上の図で提案されているレイヤ構造をもとにしてpackage構成に落とし込んだものが以下の図である． ここで，実線は依存，点線は実装を表している． このpackage構成について，サンプルコード付きの解説をここでしているので，もし興味があれば読んでください． しかし，このpackage構成では次のような問題がある． 1. データの整合性を保つために複数モデルを扱うような処理はどこに置くのか？ 2. ドメインモデルに持たせるべきではない処理はどこに置くのか？ それぞれ，詳しく説明していく． データの
[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほ
![[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f74c5c72ebd18816032917216eeec82801e95ef/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-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCREREJTVEJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JTIwJTJCJTIwJUUzJTgyJUFBJUUzJTgzJThCJUUzJTgyJUFBJUUzJTgzJUIzJUUzJTgyJUEyJUUzJTgzJUJDJUUzJTgyJUFEJUUzJTgzJTg2JUUzJTgyJUFGJUUzJTgzJTgxJUUzJTgzJUEzJUU2JUE2JTgyJUU3JTk1JUE1JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz05MGViZDg5M2ZkOGVlMDZkMGEyOWVkZWMyN2MxMmFkNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBsaXR0bGVfaGFuZF9zJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02YmZmYzI2ZTBkMjNhZjllYjRjZTJiYTQwODIzMjhhNA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Da55a404321a639c6fc4f1c3992cbb2b3)
ドメイン駆動設計を導入するために転職して最初の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)
neue cc - UnitGenerator - C# 9.0 SourceGeneratorによるValueObjectパターンの自動実装とSourceGenerator実装Tips
ValueObjectは好きですか？私は大嫌いです。いじょ。 ざっくり言えばプリミティブ型に専用の型を付ける教義です。例えばUserIdをintとして扱っているとTeamIdと取り違えるかもしれないし、Hpに突っ込んでしまうかもしれない。StrengthとIntelligenceとAgilityとSpeedは別物なのだから全部intじゃなくて区別して欲しい、そうじゃないと間違った演算しちゃうぞ、と。まぁそういう自体を避けるために、それぞれラップした個別型を作るのです。int strengthじゃなくてStrength strengthだぞ、と。 これは一見正しく実際正しいのですが、問題もあります。一つに面倒くさい。ラップしたctorを作るのだけでも定形でウザ、と思いますが、更に等値とか実装するのは面倒くさい。また、そのままだと計算できなくなるので、算術演算のために生の値を.Valueで取り
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
【難易度別】ドメイン駆動設計 (DDD) の書籍 +α のまとめ - 完全に理解した.com
ソフトウェア開発に数年以上携わっていると、どこかで「ドメイン駆動設計 (DDD)」という言葉を耳にして学んでみようと思うことが少なくないと思います。 この記事では DDD に関する日本語の書籍を DDD のバイブル的な書籍 かなり噛み砕いて解説した書籍 DDD と相性が良いとされる要件定義・設計プロセスに関する書籍 の 3 つに分けて紹介していきます。 DDD のバイブル的な書籍 エリック・エヴァンスのドメイン駆動設計 難易度: ★★★ DDD の原典のような書籍で、DDD の哲学から解説されています。 サンプルコード等のない概念的な話が多く、ページ数も非常に多いため、心が折れやすいと言われています。 あまり分厚い本を読むのに慣れていない方は、いきなりこの本を読み始めるのではなく、後述する「かなり噛み砕いて解説した書籍」のどれかから読み始めることをオススメします。 普段から分厚い本を読み慣
リアクティブマイクロサービス入門（1/2）- 概念編 - Qiita
はじめに リアクティブシステムを構築するためのライブラリ「Akka」を開発する Lightbend社 から、リアクティブシステムやマイクロサービスについて学習できる有償のオンライントレーニング「Lightbend Academy」を提供されていますが、2020年夏の間（※）は無償で受講できるようになっています。 ※2020/07/14現在。当初は無償期間が6月末まででしたが、7月末 -> 夏いっぱいと期間が延長されています。 ※「Lightbend Academy」の受講については、こちらのスライド「Lightbend Academyオンライントレーニングを受けてみた」もご参照ください。 この記事では「Lightbend Academy」を受講して学んだ、リアクティブな性質を備えたマイクロサービスを設計・開発するために知っておきたい知識や理論 を、私なりに整理・再編してご紹介したいと思いま
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
商品リンクはこちら https://little-hands.booth.pm/items/1835632 DDDはドメインモデリングを通じてソフトウェアの価値を高めようとする設計・開発手法です。 新しく得られたモデルに関する知見を頻繁にコードに落とし込む必要があるのですが、 それはソフトウェアにとっては非常に高い要求をしていることになります。 そこでDDDでは、オブジェクト指向の手法を利用して、メンテナブルで、拡張性の高いコードを書くことを目指しています。 このセッションでは、DDDではモデリング結果をどのようにコードに落とし、どのような利益を得られるのかを、具体的なコードを交えながら解説します。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDRA, ICONIX, DDDの実践から得た学び
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
