![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2023-05-15T04:47:24+00:00","default:admin","admin") #author("2023-06-13T11:19:24+00:00","default:admin","admin") -[[公式サイト:http://domaindrivendesign.org/]] -[[10分でわかるドメインモデリング:https://little-hand-s.notion.site/10-f79853f8e1e54f429e14ad9cecc87f35]] --[[さようなら軽量DDD。10分でわかるドメインモデリング - ドメイン駆動設計:https://www.youtube.com/watch?v=HgtCKlOzRiQ]] --[[ライブモデリングとコーディングで理解するDDD (DDD勉強会2021#1):https://www.youtube.com/watch?v=A2EU0paEVJ0]] -[[世界でいちばんわかりやすいドメイン駆動設計:https://www.slideshare.net/masuda220/ss-115547910]] -[[ドメイン駆動設計 本格入門:https://www.slideshare.net/masuda220/ss-137608652]] -[[DDDを試行錯誤しながら実践するチームの学びをまとめてみた:https://techblog.gaudiy.com/entry/2021/09/10/173147]] -[[3つのキーワードで学ぶ、ドメイン駆動設計の基礎知識:https://logmi.jp/tech/articles/310424]] -[[よくわかるドメイン駆動設計の考え方 従来の設計との違いと、ゲーム開発での活用法:https://logmi.jp/tech/articles/310537]] -[[オブジェクト指向プログラミングとドメイン駆動設計を学ぶのに適切な書籍とおすすめの読む順番:https://qiita.com/yushi_koga/items/655fd11396f6b502eaa4]] -[[パターンからわかりやすく入門するドメイン駆動設計（DDD）｜研修コースに参加してみた:https://www.seplus.jp/dokushuzemi/blog/2022/06/get_started_ddd_patterns.html]] -[[DDDのチーム理解度をレベルMAXにする方法（アーキテクチャ編）:https://blog.wh-plus.co.jp/entry/2021/12/21/000000]] -[[おい！なんでその処理をコントローラに書いているんだい？:https://zenn.dev/marty_ojiya/articles/ada4528d2b619c]] -[[TDD Boot Campの@t_wadaさんの基調講演:https://youtu.be/Q-FJ3XmFlT8?t=1145]] -[[Domain Driven Design（ドメイン駆動設計） Quickly 日本語版:http://www.infoq.com/jp/minibooks/domain-driven-design-quickly;jsessionid=E8C1652BF2AAC131C2E54001B3266405]] --[[PDF:http://www.infoq.com/resource/minibooks/domain-driven-design-quickly/ja/pdf/DomainDrivenDesignQuicklyOnline_JP.pdf]] -[[ドメイン駆動設計 モデリング/実装ガイド:https://little-hands.booth.pm/items/1835632]] -[[ドメイン駆動設計 基本を理解する:https://www.slideshare.net/masuda220/ss-59756718]] -[[3つのキーワードで学ぶ、ドメイン駆動設計の基礎知識:https://logmi.jp/tech/articles/310424]] -[[ドメイン駆動設計は何を解決しようとしているのか[DDD]:https://qiita.com/little_hand_s/items/721afcbc555444663247]] -[[ドメイン駆動設計を成功させるためのICONIXプロセスを考える:https://logmi.jp/tech/articles/323010]] -[[ドメインモデルとは(「現場で役立つシステム設計の原則」より):https://qiita.com/jimpei/items/93671b4b09407f9d4111]] -[[ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD]:https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month]] -[[「実践ドメイン駆動設計」から学ぶ DDDの実装入門 2.2ドメイン をマインドマップでアウトプット:https://qiita.com/michida/items/7ed98b59e17a064cd39a]] -[[DDD with RDRA, ICONIX:https://speakerdeck.com/j5ik2o/ddd-with-rdra-iconix]] -[[ドメイン駆動設計の中核は「Design」である。近い未来に訪れる組織変化に「DDD」は最適なソリューションになり得るのか:https://tech.forstartups.com/entry/2023/05/15/114714]] *概要 [#be57db19] **キーワード [#ecd90615] ***ドメイン [#acb14e6d] 問題領域、対象領域 **特徴 [#v96c0c6a] ***ドメインロジックに焦点を合わせる [#h99aae64] -ドメインの状況を表している値の種類をまず見つける -それに対してどんな計算ロジック、判定ロジックがあるかということを見つけ出す -その判定結果や計算結果をどう表現するかを決める -以下はドメインロジック以外の関心事 ＝ ドメインロジックに従属すべき関心事 --画面の入出力 --DBアクセス --API -ドメインロジックに焦点を合わせる理由 --ソフトウェアの複雑さの原因は、ドメインロジック（計算ロジックと判定ロジック）にある --ドメインロジックと入出力が混在していると、ドメインロジックの全体像や構造が見えてこない --入出力の関心事を分離して、ドメインロジックだけを対象にすると、ドメインロジックの輪郭や構造がはっきりしてくる --ドメインロジックの輪郭や構造が見えてくると、計算ロジックと判定ロジックの発見が進み、ロジックの整理がやりやすくなる --計算ロジックと判定ロジックが整理できると、入出力の記述もシンプルになる --ソフトウェア全体の見通しが良くなり、変更が楽で安全になる ***オブジェクト指向でモジュール化する [#m6d6143e] -入出力単位のモジュール化 -値の種類ごとのモジュール化 ***インクリメンタルに設計する [#r3f162ae] -対象領域の知識を少しずつ広げ、掘り下げる -最初に書いたコードを見直しながら改善する -時間とともに具体的で詳細になっていく要求を、時間とともにコードに反映する -時間とともに変化する要求を、時間とともにコードに反映する **ドメインモデルを表現する要素 [#ef43c0f0] ***エンティティ (参照オブジェクト) [#b9c07b00] ドメインモデル内のオブジェクトであり、その属性によってではなく、連続性と識別性によって定義される。 ***値オブジェクト [#z0a6ec42] 事物の特性を記述するオブジェクトである。特に識別する情報はなく、通例、読み出し専用のオブジェクトであり、Flyweight パターンを用いて共有できる。 ***サービス [#v09ec342] 操作がオブジェクトに属さない場合に、問題の自然な解決策として、操作をサービスとして実現することができる。サービスの概念は、GRASPにおいて"純粋人工物"と呼ばれるものである。 ***リポジトリ [#i2e3e583] ドメインオブジェクトを取得するメソッドは、記憶域の実装を簡単に切り替えられるようにするため、専門のリポジトリオブジェクトに処理を委譲するべきである。 ***ファクトリー [#e0841620] ドメインオブジェクトを生成するメソッドは、実装を簡単に切り替えられるようにするため、専門のファクトリーオブジェクトに処理を委譲するべきである。 **DTO (Data Transfer Object) [#f3dd519b] **DPO (Data Payload Object) [#g10d81dd] *他の設計方法との比較 [#t97f6add] *モデリング [#n027bfe3] -[[ドメイン駆動設計の2つのモデリング手法 ユースケース図とドメインモデル図をどう作る？:https://logmi.jp/tech/articles/322835]] -[[ドメイン駆動で開発する ラフスケッチから実装まで:https://www.slideshare.net/masuda220/ss-67985065]] -[[DDDのモデリングとは何なのか、 そしてどうコードに落とす:https://www.slideshare.net/koichiromatsuoka/domain-modeling-andcoding]] -[[DDD ドメインモデリングサンプル:https://qiita.com/little_hand_s/items/dfa4b156f533ba1a1491]] **戦略的モデリング [#r7610c0c] **戦術的モデリング [#w62ccbc9] **ユースケース図 [#l8be6e71] -モデリングする際は、必ずユースケース図から始める --モデリングというのは何か問題を解決するために現実世界の一部を抽象化することなので、どのように使用するのかを定めなければモデリングの目的がわからなくなってしまうから -ユースケース図を書くことで、モデリング参加者の間でモデルの用途の認識が揃う -モデリングするスコープを限定する効果もある -大概において、システム化したいものは多くあるので、スコープを切らないと際限なく広がってしまい話が発散してしまいがち **ドメインモデル図 [#ibab3dee] *アーキテクチャ [#d69929a5] -[[[DDD]ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か:https://qiita.com/little_hand_s/items/ebb4284afeea0e8cc752]] **オニオンアーキテクチャ [#g3375be2] -[[[DDD]ドメイン駆動 + オニオンアーキテクチャ概略:https://qiita.com/little_hand_s/items/2040fba15d90b93fc124]] *言語別 [#j46b903c] **Go [#gaa9789a] **PHP [#j942d2cf] -[[【PHPでDDD】ドメイン駆動設計と上手く付き合う方法:https://zenn.dev/dany/articles/b45e7e1e4639ce]] *オーガニグラフ [#p1bc2aae] -[[Organigraphs: Drawing how companies really work:https://www.researchgate.net/publication/12693544_Organigraphs_Drawing_how_companies_really_work]]
