【DDD】ドメイン駆動設計【エリック・エヴァンス】

**デフォルトの名無しさん** · 2017/10/24(火) 19:39:06.49

第1部　ドメインモデルを機能させる

　　　ドメイン駆動設計におけるモデルの有用性
　　　ソフトウェアの核心

第1章知識をかみ砕く
　　　効果的なモデリングの要素
　　　知識のかみ砕き
　　　継続的学習
　　　知識豊富な設計
　　　　　　例1.1——隠された概念を引き出す
　　　深いモデル

第2章コミュニケーションと言語の使い方
　　　ユビキタス言語（UBIQUITOUS LANGUAGE）
　　　　　　例2.1——貨物輸送プログラムを完成させる
　　　声に出してモデリングする
　　　1つのチームに1つの言語
　　　ドキュメントと図
　　　　　　書かれた設計ドキュメント
　　　　　　実行可能な基盤
　　　説明のためのモデル
　　　　　　例2.2——輸送業務と経路

第3章モデルと実装を結びつける
　　　モデル駆動設計（MODEL-DRIVEN DESIGN）
　　　モデリングパラダイムとツールによるサポート
　　　　　　例3.1——手続き型からモデル駆動へ
　　　骨格を見せる：なぜモデルがユーザにとって重要なのか？
　　　実践的モデラ（HANDS ON MODELERS）

**デフォルトの名無しさん** · 2017/11/04(土) 05:04:45.77

お前らががO/Rマッパーの中身を作ったことがあるならいいけど
そうじゃないと、その便利なO/Rマッパーに自分の技術者としての
存在価値を食い殺されることになるから気をつけろ。
DIY: 1度は作れ。最初から既存の便利なものは買うな、取り寄せるな。
DRY: 同じモノは2度も作るな。
つまり「自分の力で1度だけ作れ。」
0回もダメ, 2回以上同じモノを何度も作るのもダメ。

**デフォルトの名無しさん** · 2017/11/04(土) 08:52:57.07

DDDってこんな感じじゃん？

画面: 集約ルートのメソッドのパラメータを入力させる
コントローラ: 入力をVOに変換してサービスに投げる
サービス: リポジトリから集約ルートとってくる & 集約ルートのメソッド呼び出す ; 集約ルートをリポジトリに保存する

でもユーザーが求めてるものってこれじゃないんだよね

画面: テーブル(データそのもの)を自由に編集 & 入力に間違いあれば警告 & 入力サポート処理
コントローラ: データ層に丸投げ
データ層: 受け取ったデータをそのまま保存する & 場合によりSQLでビジネスロジックを実行して結果を保存

ユーザーはこういうアプリケーションが大好き
とにかくひとつの画面に関連ありそうなものが全部見えて全部入力できないと気が済まない
集約ルートとか関係なしにぶら下がってるエンティティも直接編集したい
理想像はエクセルを機能拡張したようなもの
そのかわり入力に間違いがないようにバリデーションだけは異様にしっかりする

DDDはユーザーが求めてるものとは違うんだよ
エレガントなアプリを作りたいっていう開発者の都合でユーザーの求めているものとは全く異なるものを作ったら、優秀な技術者じゃなくて、ニーズが読めない二流って評価されちまう

MicrosoftもそれがわかってるからASP.NET MVCやEFのようなフレームワークを作った
ビューモデル、データモデルは振る舞いを持たない素朴なデータの集合の方がわかりやすいし楽だと割り切った
そして検証の工数を下げるために属性バリデーションが発達した
これは他の言語でもだいたい同じ
世界のトップレベルの開発者たちがDDDを否定して貧血ドメイン+強力な検証というパターンを選択した

**デフォルトの名無しさん** · 2017/11/04(土) 09:24:40.15

今の仕事ドメインもどきの実装になってる

サービスは細かく区切ってあるけど
おのおの自分の担当データの整合性が保たれることだけを保証する

読み出しは自由

**デフォルトの名無しさん** · 2017/11/04(土) 13:26:31.92

>>38
どこでどう勘違いしたらそんな理解になるの？

**デフォルトの名無しさん** · 2017/11/04(土) 13:40:02.20

>>40
反論は最低限、論理的にお願いします

**デフォルトの名無しさん** · 2017/11/04(土) 14:50:46.68

論理的推論（ろんりてきすいろん、英: logical reasoning）は、
論理学において演繹、帰納、アブダクション（仮説形成）の3種類に区別されうる。
「前提条件」（precondition）、「結論」（conclusion）、
そして「『前提条件』は『結論』を含意する」という
「規則」（rule）があるとすると、それら3種の推論は次の仕方で説明されうる。

演繹
演繹は「結論」を規定することを意味する。この推論は
「規則」と「前提条件」を用いて「結論」を導くことである。
例えば、「雨がふると芝生は湿る。雨がふっている。したがって、芝生は湿っている。
」数学者は通常、この種の推論にかかわっている。
帰納
帰納は「規則」を規定することを意味する。この推論は「前提条件」の次に起こる
「結論」の諸事例の一部から「規則」を学ぶことである。
例えば、「これまで、雨がふるといつも芝生は湿ってきた。
したがって、雨がふると芝生は湿る。」
科学者は通常、この種の推論にかかわっている。
アブダクション（仮説形成）
アブダクション（仮説形成）は過去事象についての「前提条件」
を推定することを意味する。この推論は現在確定される
「結論」と「規則」を用いて「ある『前提条件』が『結論』を
説明することができるだろう」ということを裏づけることである。
例えば、「芝生が湿っている。雨がふると芝生が湿る。
したがって、雨がふったに違いない。」
歴史科学者や診断専門医、探偵は通常、この種の推論にかかわっている。
https://ja.wikipedia.org/wiki/%E8%AB%96%E7%90%86%E7%9A%84%E6%8E%A8%E8%AB%96

**デフォルトの名無しさん** · 2017/11/04(土) 18:46:52.01

反論はないということですね
やっぱりDDDはアンチパターンなんだ

**デフォルトの名無しさん** · 2017/11/04(土) 19:11:47.69

貧血ドメインごとに専用のサービスクラスを作るのはトランザクションスクリプト？

**デフォルトの名無しさん** · 2017/11/04(土) 21:10:36.19

>>43
DDDの提唱者ですら言ってるよ
ビジネスロジックが複雑でないドメイン、例えばただのCRUDみたいに、
DBのUIでしかないようなアプリはDDDでやる意味ないって

**デフォルトの名無しさん** · 2017/11/04(土) 21:21:57.79

>>45
その複雑なドメインってのがそもそも現実的じゃないんだよ
すべてのアプケーションはDDDなしでの高生産で作れるんだし

**デフォルトの名無しさん** · 2017/11/04(土) 23:23:48.00

>>44
それ分ける意味って何なの？
わざわざ実装散らしてメンテする人に嫌がらせしたいの？

**デフォルトの名無しさん** · 2017/11/04(土) 23:34:10.39

>>47
Entity Frameworkが使えるよ
DBからエンティティクラスを自動生成できるのさ
トランザクションスクリプトの弱点は機能が重複することだから
エンティティごとにサービスクラス作ればその弱点を補える
現実的な落としどころとして最高だと考えるわけだが

**デフォルトの名無しさん** · 2017/11/05(日) 00:21:31.23

>>48
既存DB前提のCRUDアプリならわかるけど、それ以外の場合はどうすんの？
インピーダンスミスマッチもない前提？
DB用に正規化されたデータがUIまで貫通するの？

**デフォルトの名無しさん** · 2017/11/05(日) 00:23:40.39

>>49
EntityFramework使ったことない人？

**デフォルトの名無しさん** · 2017/11/05(日) 00:25:55.15

>>50
使ったことない前提でいいから質問に回答が欲しい

**デフォルトの名無しさん** · 2017/11/05(日) 01:38:13.55

>>51
正規化されたテーブルとEntityは必ずしも1:1にはならないし、そのEntityをUIでそのまま使うのはアンチパターン。

**デフォルトの名無しさん** · 2017/11/05(日) 02:01:55.97

>>52
>>48でDBから自動生成する話してるのに1:1じゃないの？
コードファーストの話してるならならわかるんだけど。

**デフォルトの名無しさん** · 2017/11/05(日) 02:37:13.36

>>38
＞理想像はエクセルを機能拡張したようなもの
スマートUIの方が作りやすいが変更に弱い

＞世界のトップレベルの開発者たちがDDDを否定して
いやこれは違うぞ

欧米ではDDDのようなドメインモデルを選択してる
日本がガラパゴスで遅れてるだけ

**デフォルトの名無しさん** · 2017/11/05(日) 02:42:39.47

>>45>>46
CRUDならDB＋スマートUIで良いが
複雑なドメインや変更が多いアプリはDDDが向く

＞すべてのアプケーションはDDDなしでの高生産で作れる
これは違う

スマートUIやトランザクションスクリプトの方が作りやすいが
変更に弱いので長期的には保守が大変で行き詰まってくる

**デフォルトの名無しさん** · 2017/11/05(日) 06:59:58.30

>>53
自動生成したものをそのまま使うんならそうだね。普通はそんなことあまりしないけど。

**デフォルトの名無しさん** · 2017/11/05(日) 08:00:27.84

>>54
それホントなの？
外人が書いた技術書見てもトランザクションスクリプトは大抵の場合うまく行くって書いてあるよ
ドメインモデルは大抵の場合大失敗するって

**デフォルトの名無しさん** · 2017/11/05(日) 08:03:34.39

UIでエンティティをそのまま使うってめちゃくちゃなこと言ってそれを批判する自作自演論法を駆使してる人を見て頑張り屋さんだなあと思うなど

**デフォルトの名無しさん** · 2017/11/05(日) 08:05:12.56

ジャパニーズはドメインモデルを天皇か何かだと思っているのではないかと思うなど

**デフォルトの名無しさん** · 2017/11/05(日) 08:06:45.10

欧米マジ凄えからマジ

**デフォルトの名無しさん** · 2017/11/05(日) 08:09:27.54

連投すると書き込めなくなるな

**デフォルトの名無しさん** · 2017/11/05(日) 08:18:06.55

天皇ってキーワードが引っ掛かったんじゃね

俺もいろいろ書き込みしてるが
決まって煽ろうとしたときだけ
なんか変ないろんなルールに引っ掛かる

実際はＡＩが仕込まれていて
都合の悪い書き込みだけルールをこじつけてはじいているのでは

**デフォルトの名無しさん** · 2017/11/05(日) 08:23:12.21

日本人のDDDに対する信仰はいったいなんなんだろうな？
DDDを取り入れてない企業の若者ほどDDDに傾倒してる気がする
お前らDDDやったことないやろwww

**デフォルトの名無しさん** · 2017/11/05(日) 08:31:03.39

データと振る舞いが分離して処理があちこちにばらまかれるって言う奴がいるけど
それって設計が雑でレビューもしてないだけだよね
普通に作ればトランザクションスクリプトでも疎結合高凝集になるし

**デフォルトの名無しさん** · 2017/11/05(日) 08:35:38.15

ぶっちゃけ並み以上のスキルと統制力があればDDDでも貧血ドメイントランザクションスクリプトでもうまくいく
そしてそれはシステムの複雑度とは関係ない

それを踏まえて考えるとモダンなフレームワークの恩恵を受けにくいDDDは現代ではアンチパターンなんだな
フレームワークが未成熟な時代に考えられたアイデアだし時間が経って陳腐化するのは仕方がないけど

**デフォルトの名無しさん** · 2017/11/05(日) 14:12:32.46

>>65
フレームワークのロックインを避けて移植性を高めたい場合は？

**デフォルトの名無しさん** · 2017/11/05(日) 14:25:33.60

トランザクションスクリプト推しとの議論スレにじゃなくて、DDDをうまくやる方法を語れるスレになってほしいな
なんでOO系のスレってアンチが粘着しがちなんだろう

**デフォルトの名無しさん** · 2017/11/05(日) 14:46:35.78

>>66
移植する予定が出てきてから考えればいいよ
現実的な線で言うとDDDにするコストより地道に移植するコストのほうが安いけどな

**デフォルトの名無しさん** · 2017/11/05(日) 14:51:12.32

>>67
本当に優れた手法なら批判的な意見を正論で叩き潰せるはず
俺はそれを見てみたいんだよ
実は俺はDDDアンチじゃなく信者だからね
他人の意見は上司を説得して業務に取り入れるための参考になる
はやく論破してくれ

**デフォルトの名無しさん** · 2017/11/05(日) 15:09:40.83

>>69
論破っていうけどさ、

> 現実的な線で言うとDDDにするコストより地道に移植するコストのほうが安いけどな

みたいな、根拠も示さない意見を論破する労力なんて誰も割きたくないでしょw
いや、うちはDDDで移植のコストは下がったけどな、って返せばいいの？

**デフォルトの名無しさん** · 2017/11/05(日) 15:16:50.90

>>70
移植先のフレームワークも似たような機能が揃ってるから大した手間にならん
フレームワークに沿って高生産の仕事を2回やるだけ
しかもフレームワークは似てるので2回目はさらに簡単

生産性をあげるのがフレームワークだ
それに逆らってDDDをやっても生産性を下げるだけ
移植するときにもまた他のフレームワークに逆らうことになり生産性を下げざるをえない
苦痛を2回も強いられる

**デフォルトの名無しさん** · 2017/11/05(日) 15:33:43.90

まず、DDDはフレームワークに逆らっている、というのがよくわからん
具体的にはどういうこと？

**デフォルトの名無しさん** · 2017/11/05(日) 15:38:24.62

>>72
フレームワークを使った開発ではプレーンなオブジェクトに属性を付けて不変条件を守るスタイルが優勢

DDDは余計なメンバを公開しないしインフラから切り離すので属性にも依存したくない
フレームワークの利点を潰してしまう

**デフォルトの名無しさん** · 2017/11/05(日) 15:58:00.31

具体的なフレームワーク名も挙げずに何言ってんのこいつ

**デフォルトの名無しさん** · 2017/11/05(日) 16:00:49.98

>>74
最近のフレームワークはどれも同じようなものって言ってるだろ
なら具体的にあげる意味はないね

**デフォルトの名無しさん** · 2017/11/05(日) 16:04:04.40

>>75
知らないだけ

**デフォルトの名無しさん** · 2017/11/05(日) 16:04:32.12

>>75
具体例を

**デフォルトの名無しさん** · 2017/11/05(日) 19:48:21.92

サービス層とMVCのコントローラは何が違うのか
情弱の俺に教えてくれよ。

**デフォルトの名無しさん** · 2017/11/05(日) 20:15:07.05

>>68
最初から予定してる場合は？

**デフォルトの名無しさん** · 2017/11/05(日) 20:21:57.83

>>78
サービスって言葉は色んな意味で使われるから分かりにくい
特定のクラスに属するとマズイ処理を実装するところだと理解してるけど

MVCのCはそのまんまUIとモデルの橋渡しでしょ

**デフォルトの名無しさん** · 2017/11/05(日) 20:29:14.50

ドメインモデルっていうくらいなんだから
サービスドメインはモデルでしょうな

**デフォルトの名無しさん** · 2017/11/05(日) 21:16:49.89

>>63
その割にはドメインに対する理解とかには全然注力しない印象。
業務系だったら、簿記や会計の勉強したりとか。

**デフォルトの名無しさん** · 2017/11/05(日) 21:20:40.35

>>67
＞OO系のスレってアンチが粘着しがち
OOが難しいから否定したいんだろう
関数型のスレにもいるだろ

**デフォルトの名無しさん** · 2017/11/05(日) 22:13:53.69

>>78
似てるけど微妙に違う

Mにドメイン層とインフラ層が一緒になってるのは分かるよな
サービス（アプリ）層はCとMの一部が一緒になってる

**デフォルトの名無しさん** · 2017/11/06(月) 00:29:31.84

ここは軽量DDDを議論するところなの？

**デフォルトの名無しさん** · 2017/11/06(月) 13:22:13.87

>>84
リクエストとレスポンスのインタラクションは
コントローラ
データの「加工」「変換」「検索」「演算」「結合」
ここらへんが絡む物はサービス?
DBMSのコネクションの利用はモデルじゃなくてサービスかな
モデルはただ単に「属性」を持っているだけでいい。
それと最低限のゲッターとセッター
こんなところだろうか？？
バリデーションや業務ルールのチェックはモデル？？サービス？？

**デフォルトの名無しさん** · 2017/11/06(月) 19:18:41.19

考えるな　感じるんだ

じゃなくて
周りに合わせるんだ
どんなくそ設計でも検証通ったコードと一貫性が保たれてるほうが品質高い

サービスだとおもいます

**デフォルトの名無しさん** · 2017/11/10(金) 15:55:49.97

他人が構築したドメイン構造を把握するスキルも
重要なのかな?
日本のSIlerの場合常駐先がしょっちゅう変わったりする
んだからそうなるとドメインを構築しようとか
どんなドメインなのかの把握が面倒になってしまう。

**デフォルトの名無しさん** · 2017/11/10(金) 21:17:00.97

>>86
いろんな考え方があるけど一番シンプルなのは
DDDではドメインが一番大事だからドメインと他を切り分けること

UIとDBは明らかに分かると思うからそれをどけて
残るのはアプリ（サービス）層とドメイン層の区別

両者は混同されやすくサービスの肥大化がよく起こるので
リファクタリングを続けて継続的に
ドメインの知識はドメイン層へと移動させていく

＞バリデーションや業務ルールのチェック
たしかにこれはどっちに置くか難しいけど
私ならドメインの知識になってるかどうかで考える

たとえばよくある例では日付でうるう年の判定などは
明らかにドメインの知識だからドメイン層に置く

**デフォルトの名無しさん** · 2017/11/12(日) 10:23:37.61

バリデーションはエラーメッセージ、UIの強調表示なども絡むからどう考えたってプレゼンテーション層でしょ
ビューモデル(プレゼンテーションの都合であるモノ)のプロパティ属性にバリデーションルールを書くことが標準的になっている点からもこの事実は明らか

**デフォルトの名無しさん** · 2017/11/13(月) 07:29:43.51

>>90
ASP.NETだけどビューにバリデーション書いたとしてjavascriptゴニョゴニョされてバリデーション突破されたら怖いからコントローラにもチェック入れてる
設計的に正しいのかは解らない

**デフォルトの名無しさん** · 2017/11/13(月) 08:20:06.77

>>91
>>90とやってること一緒じゃね？

**デフォルトの名無しさん** · 2017/11/13(月) 08:41:32.54

目的が違えば両方あってもいいんじゃね？ユーザーの利便のためか自衛のためか。

**デフォルトの名無しさん** · 2017/11/13(月) 09:17:00.78

>>91
ASP.NETって、ビューモデルのバリデーションをクライアント側のJSで突破できちゃうの？

**デフォルトの名無しさん** · 2017/11/13(月) 12:08:35.87

ジャバオのバリデータだろ

**デフォルトの名無しさん** · 2017/11/13(月) 18:48:33.23

>>94
そう書いたらそうなる
普通はControllerでチェックする

**デフォルトの名無しさん** · 2017/11/13(月) 20:17:19.09

>>90
クライアントのJSで検証したらサーバー側のコントローラで検証しなくても良いと？
んなわけねーだろ普通両方やるわ

**デフォルトの名無しさん** · 2017/11/13(月) 22:06:30.64

プレゼンテーション層でチェック
クライアントでチェックする

一緒にしてる奴がいるね
ちなみにコントローラーもプレゼンテーション層な

**デフォルトの名無しさん** · 2017/11/14(火) 05:47:03.90

>>98
>>97は
https://blogs.msdn.microsoft.com/nakama/2009/09/28/293/
で触れてるような信頼境界の話だろ

**デフォルトの名無しさん** · 2017/11/14(火) 07:18:29.77

>>98
Controlerってアプリケーション層じゃ無いんだ
出典無いから自信無いけど

**デフォルトの名無しさん** · 2017/11/14(火) 19:38:43.49

セキュリティとか悪意のある攻撃を想定すると
話が厄介になるね
セキュリティ考慮でなければ、情報の源泉に近い
JSでバリデーション1本だけで十分だろう。
セキュリティとか認証が絡むとこういったレイヤの層分け
が狂う要因になるのだろうか？

**デフォルトの名無しさん** · 2017/11/15(水) 03:47:42.79

>>101
仕事で使うなら想定しないケースも希だと思うけど

**デフォルトの名無しさん** · 2017/11/16(木) 07:24:52.29

DIのフレームワークとDDDって共存できるの

DDDってMVCみたいなレイヤードアーキテクチャからドメイン抜き出したもの程度しか認識ない人間だけど

**デフォルトの名無しさん** · 2017/11/16(木) 07:30:52.62

>>103
MVCはレイヤードアーキテクチャじゃないよ

**デフォルトの名無しさん** · 2017/11/16(木) 12:33:04.40

>>104
モデルビューコントローラはレイヤじゃ無いのか
そう言えばモデル層とか聞かないね

**デフォルトの名無しさん** · 2017/11/17(金) 08:39:38.18

validationとormがDDDのボトルネック
要するに机上の空論

**デフォルトの名無しさん** · 2017/11/17(金) 23:50:35.86

UIの要求が強すぎるとうまくいかんのだわ
ドメインクラスをフロントとバックの両方に書くはめになる
Node.jsだとそのへんうまくいくのかな

**デフォルトの名無しさん** · 2017/11/18(土) 13:44:21.91

お前ら設計書ってどうしてる？
仕事でやる以上は設計書出せと言われたら書かなきゃならない
設計書がレビュー通らなきゃコーディングは始められない
バリューオブジェクトの設計書とかあまりにも馬鹿馬鹿しいんだけど何百個も書かなければならない

**デフォルトの名無しさん** · 2017/11/18(土) 15:21:12.87

>>108
なんて言ってほしいのかわからない
仕事なんだからやれって言われたらヤるしないって立場なんでしょ？
じゃあやるしかないじゃん

バリューオブジェクト数百個っていったらそれなりの規模のシステムだろうから
バリューオブジェクトを使わなかったとしてもどうせ大量の設計書を書かないといけないし、
今となってはそういう仕事を受けたのを悔やむことぐらいしかできないのでは？

**デフォルトの名無しさん** · 2017/11/18(土) 15:39:25.13

しかも設計書がExcel方眼紙なんだよな。

**デフォルトの名無しさん** · 2017/11/18(土) 15:47:54.83

設計書なんで実装終わったときに揃ってれば良いだろ
どうせ開発中にコロコロ仕様変わるなんてよくある話だ

**デフォルトの名無しさん** · 2017/11/18(土) 16:01:31.09

レビューがあるから先に設計書を書かないとダメ
でも設計書で設計するとグダグダになる
設計書から目をそらす以外にうまくいく方法があるなら教えてくれ

**デフォルトの名無しさん** · 2017/11/19(日) 08:43:56.41

テキトーに書いておく
レビューする側に解ってる人がいるのは稀だからタイテーはこれで何とかなる

**デフォルトの名無しさん** · 2017/11/19(日) 11:30:11.10

先にユニットテスト済みのコードを書く
doxygenで設計書生成
レビューしてOKを貰う
コーディングしてるふりして1日サボる
コードをプッシュ

**デフォルトの名無しさん** · 2017/11/19(日) 12:43:48.77

>>114
doxygenってExcel方眼紙出せたっけ?

**デフォルトの名無しさん** · 2017/11/19(日) 13:09:42.41

エクセル設計書なんて使わない

**デフォルトの名無しさん** · 2017/11/19(日) 13:56:40.03

>>116
使いたかないけどさ。
たぶん >>108 にそんな自由はない。

**デフォルトの名無しさん** · 2017/11/19(日) 16:15:48.08

Excelに貼り付けるテキストを自作ツールで出力。

**デフォルトの名無しさん** · 2017/11/22(水) 15:13:08.97

ビジネスロジック層と永続化層の違いについて聞きたいんだが
「ビジネスロジック」は「犬」とか「リンゴ」とかいうクラスを作る層で
「永続化層」は「犬テーブルを操作するオブジェクト」を定義するクラス
を作る（というかPDOとかActive Recordとかが用意している)という
認識でいいのか?

**デフォルトの名無しさん** · 2017/11/22(水) 18:17:46.26

ざっくり言うとデータベースに関係あるのがインフラ層

**デフォルトの名無しさん** · 2017/12/05(火) 00:47:41.31

エヴァとのコラボカードナナコ最高。http://maeda-gourmet.jp/2016/09/09/nanaco/

**デフォルトの名無しさん** · 2018/05/23(水) 21:07:55.14

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

Q3XKO

**デフォルトの名無しさん** · 2018/07/05(木) 00:49:06.04

ZJY

**デフォルトの名無しさん** · 2018/09/09(日) 06:43:58.22

ゲーム開発でDDDは使えますか？
その場合のドメインとドメインエキスパートとは例えば何、誰を指すでしょうか？

**デフォルトの名無しさん** · 2018/10/08(月) 00:49:59.53

ボトムアップドメイン駆動設計
https://ddd-community-jp.connpass.com/event/103428/

ぜひ参加してください！

**デフォルトの名無しさん** · 2018/10/11(木) 20:53:29.46

Eric Evans氏はドメイン駆動設計(DDD) は未完成だと述べた
https://www.infoq.com/jp/news/2018/10/ddd-not-done

**デフォルトの名無しさん** · 2018/10/24(水) 09:23:12.56

>>125
講師がひとりで勝手に盛り上がってて寒いセミナーだったな
マーケ視点で物事を考えない典型的駄目エンジニアって感じだから内容も薄い薄い

**デフォルトの名無しさん** · 2018/10/25(木) 01:29:02.78

こんなやつらがDDDやってるんだなってのがわかって結構面白かったけどね
今日の内容で本書きます！って言われたときはさすがに周り失笑してたけど

**デフォルトの名無しさん** · 2019/03/17(日) 12:58:39.06

まだ、軽量DDDなんかやっている人がいるのね。

**デフォルトの名無しさん** · 2019/04/25(木) 08:19:51.47

意外と盛り上がらないね。

**デフォルトの名無しさん** · 2019/04/25(木) 20:00:13.26

ドメインが複雑じゃないとあんまり意味なさそうなのは感じ無くもないけど、将来の改修のしやすさのための布石と思えばいいのかな。

**デフォルトの名無しさん** · 2019/05/06(月) 12:07:22.28

>>131
　ドメインモデルが有効に機能するのって、イラレ、フォトショ、動画編集、オフィス系のようなパッケージアプリぐらいだと思う。

　普通のDB叩くアプリではいらないと思う。

**デフォルトの名無しさん** · 2019/06/20(木) 07:02:35.15

業務系はエンティティ間の関連が多すぎてリポジトリパターンと相性が悪いと思う
トランザクション分析すると集約ルートが複数のテーブル全体を巻き込んだりする

**デフォルトの名無しさん** · 2019/10/11(金) 20:14:12.01

最近DDDの本読んで勉強してるが、日本じゃ流行らなさそうだなという印象
英語圏なら確かにユビキタス言語からコードにシームレスに移れ、
コードがそのままドメインエキスパートにも読めるドキュメントにできるだろうが…

**デフォルトの名無しさん** · 2019/10/12(土) 06:32:18.26

古典的なデータモデリングのマッピング先がOOPに変わっただけという印象なんだけど。

**デフォルトの名無しさん** · 2019/10/12(土) 14:21:09.70

>>135
DDD本で紹介されてる概念やテクニックはOOPに限られたものじゃないよ
DOAの古典的データモデリングでも十分に役立つし関数型のパラダイムで実装することもできる

日本語でDDDについて書かれてる記事は質が低いのが多いから
ちゃんと理解したければEric Evansの原典かVernonの"Domain-Driven Design Distilled"を読むのを勧める

**デフォルトの名無しさん** · 2019/11/27(水) 21:15:02.91

「Hands-On Domain-Driven Design with .NET Core」Alexey Zimarev

これ結構いい本
Packtのサイトでセール中なのか今なら10$で買える