【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）

**デフォルトの名無しさん** · 2020/03/14(土) 17:55:44.71

>>171
言いたいことはわかるが、websocketみたいなコネクション管理するものを
まるまる関数型で書くなら状態変化を含んだとしてもオブジェクト的に記述した方が
多分楽。
なんでもどっちかに倒そうとすること自体が悪パターンな気がするよ。

**デフォルトの名無しさん** · 2020/03/14(土) 18:05:14.78

良いとこ取りしていけ

**デフォルトの名無しさん** · 2020/03/15(日) 00:23:36.09

>>172
WebSocketかー。やったことないからやってみよう

**169** · 2020/03/15(日) 05:56:57.78

>>170
継承や委譲で階層構造を表現できる

まあメジャー言語はたいてい
OOのパラダイム入ってるから
だいたいできるんだけど

>>171
＞状態の数だけ型作って
＞遷移の数だけ関数つくればいいだけ

実際にはゴチャゴチャになって
「大変な労力」だから
関数型が言うほど採用されないんだよ

ただ非同期で並列化が必要な場合とか
ミッションクリティカルな場合で
バグを極力出したくない場合は別の話

**デフォルトの名無しさん** · 2020/03/15(日) 08:25:11.78

>>175
あんたに限らず関数型が大規模なプログラム書くのに向かないと思ってる層がちゃんと関数型プログラミングをしたことがなく先入観でもの言ってるのはよくわかった

**デフォルトの名無しさん** · 2020/03/15(日) 08:38:54.73

>>176
あんたも決めつけで言ってるだけだろ
関数型で状態遷移を把握しづらいのは
強く実感しているし普及しない原因だ

**デフォルトの名無しさん** · 2020/03/15(日) 09:21:24.78

>>177
それはどの言語でどんなことしようとして「強く実感」したの？

関数型言語が普及しないのは、単に先入観やOOP神話の影響で学ぼう使おうと思う人が少ないからだよ。
関数型プログラミングが普及しない理由は、当然だが関数型プログラミングの諸概念を表現するのに命令型言語が不向きだから。柔道着着て水泳するようなもんだ。

**デフォルトの名無しさん** · 2020/03/15(日) 14:50:21.29

>>175
>継承や委譲で階層構造を表現できる

OOでは継承や委譲で階層構造を表現できると言われても
関数型の言語よりOO言語のほうがDDDには向いてるという論拠にはならないよ
少し古いスライドだけど、これ見て概要だけでも勉強して
https://www.slideshare.net/ScottWlaschin/domain-driven-design-with-the-f-type-system-functional-londoners-2014

**デフォルトの名無しさん** · 2020/03/15(日) 18:32:23.77

一昔前のOOP厨と一緒だな。
歴史を学ばん奴は一生ループする。

**デフォルトの名無しさん** · 2020/03/15(日) 23:47:43.93

>>179 そうだよなと得心する事が多くて良い資料ですね
ドメインに継承や移譲が要るって考えてる人は是非とも読んで欲しいし、反例を挙げて欲しくなる

**デフォルトの名無しさん** · 2020/03/16(月) 00:15:47.56

>>179
俺もこのスライドの作成者の本で関数型DDDに入門したクチだけど、本当にわかりやすかった
もともとHaskell, purescriptはやってて関数型には慣れてたけど、
DDDについては知らなかったので、せっかくだから関数型前提で書かれている本でと手にした。
Domain modeling made functional っていう本で、
DDDの解説はもちろん、関数型プログラミングの諸概念の解説もわかりやすく、
一冊で二度美味しい内容で、実用的な関数型プログラミングの入門書としても超おすすめ。

https://youtu.be/dEKvIxsERAI
ちなみにyoutubeにはこのスライドの発表動画もあったりする

**デフォルトの名無しさん** · 2020/09/16(水) 23:15:57.30

Matthias Felleisenの「How to Design Programs」を読んで関数型プログラミングに
興味を持ったものです。
次にモナドを勉強しようとしてHaskellの本を読んだがいまいちピンときません。
>>182さんが挙げられている本では、モナドを使ってモデルの実装をしているようですが、
モナドの使い方は理解できますか？

**デフォルトの名無しさん** · 2020/09/17(木) 01:01:40.98

Scalaで良ければ、manning.comからでてる　Functional and Reactive Domain Modeling にモナドでドメインサービス組み立てる話が掲載されてる。
なおFree Monadをベースとしているので軽く死ねる。

https://www.manning.com/books/functional-and-reactive-domain-modeling

**183** · 2020/09/17(木) 23:32:13.91

>>184
ありがとうございます・・・でもDomain modeling made functional をPDFでポチっちゃいました。
後で読もうと思います。
ところでDDDを学ぶ上で、大規模な開発経験が必要なんでしょうか？
自分は学生で、そのような経験がありません。
『How to Design Programs』では小さなプログラム作成の演習はありましたが、
それ以上の大きさのプログラム作成の方法はありませんでした。
DDDは大きなプログラムをつくるガイドになりますか？

**デフォルトの名無しさん** · 2020/09/22(火) 23:49:46.08

>>184
これ

**デフォルトの名無しさん** · 2020/09/23(水) 00:07:54.77

>>184
これ読んでみようかと思ったら

＞読者は関数型言語とドメイン駆動設計に慣れている必要がある

とあるんだが、読むのにドメイン駆動設計の深ーい知識は必要だった？

**デフォルトの名無しさん** · 2020/09/23(水) 06:16:40.99

DDD興味ある
大いに語るがよい

**デフォルトの名無しさん** · 2020/09/23(水) 07:12:30.61

>>187
必要最小限ではあるがScalaの文法解説と、各ドメインオブジェクトの解説は入っていたはず。
知っていれば理解が進みやすいくらいに考えてればいいはず。

**デフォルトの名無しさん** · 2020/09/23(水) 19:36:49.05

>>189
thx

**デフォルトの名無しさん** · 2020/09/30(水) 19:59:30.09

DDDもそろそろバージョンアップせんと
OOPは時代遅れ

**デフォルトの名無しさん** · 2020/12/02(水) 20:38:28.14

Freeモナドなんて言語埋め込みDSLを作るってだけ

**デフォルトの名無しさん** · 2020/12/05(土) 00:03:20.35

DDDいいよね！
なんちゃってOOPから脱出する際に役立ったよ

**デフォルトの名無しさん** · 2021/03/31(水) 07:17:34.67

DDD、CQRS、イベントソーシング…
企業内システムでここまでやってるとこってあるんだろうか
参照系中心のシステムでDDDやるのは愚行？

**デフォルトの名無しさん** · 2021/05/18(火) 06:36:21.05

おれはさとった

名前がちがうだけのValueObjectクラスだけつくって
メソッド引数の位置を間違えられないようにしときゃいいんだ
それだけでいいんだ

バリデーションは入り口でやる
中は値が正しい前提でまったくチェック不要

それがDDD

**デフォルトの名無しさん** · 2021/05/19(水) 20:38:26.97

それだけでDDDは語れないような…
いまだに集約がわからんよ

**デフォルトの名無しさん** · 2021/05/23(日) 21:05:34.48

教科書が概念的でよくわからんことばっかほざいてる時点でおかしい
サンプルを一発提示すればああこんなのねって
それで終わるだろ！？

**デフォルトの名無しさん** · 2021/07/13(火) 00:57:28.25

ガサッと取ってきて変更して全部更新！ってアホなんって思った
これの何がいいの？

**デフォルトの名無しさん** · 2021/07/13(火) 22:24:26.83

CRUD で十分な単純なアプリならいらない

**デフォルトの名無しさん** · 2021/07/14(水) 08:14:14.87

>>197
2003年頃ならともかく。OSSのアプリが溢れている今の状況ならこのアプリのこの部分はこのパターンを使っているって示せると思う。

**デフォルトの名無しさん** · 2021/08/10(火) 20:46:36.95

>>191
亀レスだが、OOPを補完するのがDDDだろうに
なんでDDDスレでOOPが時代遅れだと言えるのか疑問

**デフォルトの名無しさん** · 2021/08/10(火) 23:57:50.00

>>201
OOPより上位レイヤーの概念なのでOOPを補完するものではないよ
Eric Evansの最初の本ではDDDの実装例としてOOPが使われただけ
関数型で実装する例もある

**デフォルトの名無しさん** · 2021/08/11(水) 22:58:43.10

>>202
> OOPより上位レイヤーの概念なので
> Eric Evansの最初の本ではDDDの実装例としてOOPが使われた

そういうのを補完って言うのでは？

**デフォルトの名無しさん** · 2021/08/12(木) 23:34:58.79

>>203
お前は国語から勉強し直さないとこの先辛いぞ？
お前は概念とか言ってる場合じゃない

**デフォルトの名無しさん** · 2021/08/13(金) 08:38:17.53

ほかん
【補完】
《名・ス他》
足りない点を補って完全にすること。

OOPに足りない部分をDDDで補ってるって言いたかったのでは？
別に変だとは思えないけど

**デフォルトの名無しさん** · 2021/08/13(金) 09:30:37.30

OOPを補完するのがプログラミングだろうに
なんでプログラミングスレでOOPが時代遅れだと言えるのか疑問

OOPに足りない部分をプログラミングで補ってるって言いたかったのでは？

**デフォルトの名無しさん** · 2021/08/13(金) 11:25:44.59

OOPはプログラミングを補うものでありプログラミングがOOPを補う訳ではない

**デフォルトの名無しさん** · 2021/08/13(金) 11:56:11.61

>>205
補完などではない
そもそもOOPなどと書くから話がおかしくなる

DDDはOODを包含した概念である

**デフォルトの名無しさん** · 2021/08/13(金) 13:49:07.82

OODと言い換えたところで補完もしてなければ包含もしてない

DDDをOOの文脈でしか理解できない人は抽象概念の理解がもともと不得意なのか
日本人の書いたなんちゃってDDD本で分かったつもりになってるか
そもそもOO以外を知らないか

**デフォルトの名無しさん** · 2021/08/13(金) 14:28:21.12

お前はDDDを学んでもOOP及びOODには何の影響もないみたいだけど、俺は別にDDDで学んだ知識がOOP／OODに役立ってるので、別にどうでもいいっす。
なんで役立ったのか想像できないのなら、その程度ってことでしょう。

**デフォルトの名無しさん** · 2021/08/13(金) 15:21:02.98

ブホッw

**デフォルトの名無しさん** · 2021/08/14(土) 07:58:11.46

OOPにありがちな、車やエンジンを例にした説明より
DDDの方がしっくりくるというか
あ、OOPでこんなことができるのかと目から鱗だったな

**デフォルトの名無しさん** · 2021/08/14(土) 15:27:00.83

いつの時代になってもITの方法論は「方法論オナニストに都合のよい飯の種」の域を出ない

**デフォルトの名無しさん** · 2021/08/14(土) 15:31:45.91

建設業のように国が規格を決めてしまえばよかったんだ
国所属の認定団体に承認された関数以外使ってはいけません

**デフォルトの名無しさん** · 2021/09/16(木) 15:51:11.37

DDDとは、「ドメイン知識(モデル)」を「駆動」して「開発」する開発手法であって、何か特定のアーキテクチャをあらわすものではない

**デフォルトの名無しさん** · 2021/09/16(木) 15:54:48.85

嘘言いました
最後のDはDevelopmentじゃなくてDesignだったわ
恥ずかしー

**デフォルトの名無しさん** · 2021/09/16(木) 19:58:10.14

もーやだー

**デフォルトの名無しさん** · 2021/09/26(日) 11:30:18.78

設計はアーキテクチャを示すものじゃない
言葉が違えば意味が違う

**デフォルトの名無しさん** · 2022/05/07(土) 06:20:48.85

DDDは大量データ更新に弱い
10万件のレコードに同じ値をセットする処理に途方もなく時間がかかる

**デフォルトの名無しさん** · 2022/07/27(水) 17:37:37.82

カルト宗教だよね
設計というのはパフォーマンス要件の整理と実現に当たってのアーキテクチャを考えるために必要なわけで
機能要件にSLAがないだなんてことは設計するならばありえないし、
じゃあその要件に到達するためにシステムやミドルウェアをどう使っていくかがアーキテクトの肝なところじゃん
APPサーバに閉じた議論しかしてない時点で雑魚システムしか作れんし
雑魚システムにそもそも設計なんざいらんだろって話よ

こういう連中が言い出しそうなこと、DBは抽象化できる
そもそもファイルを保存するならテキストでもいい
依存性の逆転を駆使すればインタフェースに依存させることができるので、アプリから実装詳細が消える！

それでDBがやってくれてるトランザクション制御や成約、整合性の解決を
ファイルシステムで実装するその実装を誰が書くの？
アーキテクトを自称するなら君が書くってことだけど、いったい誰がそんなこと頼んだんだろう

**デフォルトの名無しさん** · 2022/07/27(水) 17:39:26.99

型システムの理解も貧弱、DBMSの理解も貧弱、なんならネットワーク・プロトコルの理解も貧弱

一生システム完成させる気ないやる気なしエンジニアの最後の拠り所だろ

**デフォルトの名無しさん** · 2022/07/27(水) 20:57:03.92

だいぶ詳しい反論だなw

**デフォルトの名無しさん** · 2022/07/27(水) 21:51:14.18

https://enterprisecraftsmanship.com/posts/ddd-bulk-operations/
DDDでバルク処理
そこまで拘らなくていいんじゃないかなと言う感想

**デフォルトの名無しさん** · 2023/09/22(金) 05:22:44.35

これってどうやって気にするの？

**デフォルトの名無しさん** · 2023/09/28(木) 03:45:15.07

ｺﾞｼｺﾞｼ(-_＼)(/_-)三( ﾟДﾟ) ｽ､ｽｹﾞｰ!

**デフォルトの名無しさん** · 2023/12/03(日) 23:52:03.41

テスト

**デフォルトの名無しさん** · 2024/12/06(金) 22:29:28.26

関数型DDDの本の作者のアーキテクチャが話題になっている
Repositoryはいらない
大事なのはIOをロジックの中から排除せよということらしい
以下のように"端に寄せる"

IO
ビジネスロジック
IO

目から鱗だった
IOへの依存をなくすことでテストしやすくなるしモックもいらない

**デフォルトの名無しさん** · 2024/12/07(土) 18:42:46.99

ビジネスロジックはパイプラインで構築して副作用がないようにする

**デフォルトの名無しさん** · 2024/12/08(日) 00:14:30.46

DDDは素晴らしいと思うけど、プロジェクト内の他エンジニアのスキルが低いとアンチパターンになるんだよな

**デフォルトの名無しさん** · 2024/12/08(日) 14:38:22.52

DDDって再現性ないじゃんw
偽科学

**デフォルトの名無しさん** · 2024/12/08(日) 15:54:58.48

設計に再現性はないよ
要件が全く同じということがないから
だから難しい

**デフォルトの名無しさん** · 2024/12/08(日) 15:56:35.36

IOを"端に寄せて"ビジネスロジックはパイプラインで実行して不変データ構造にするというアイデアマジで凄い
これからこの設計にする

**デフォルトの名無しさん** · 2024/12/08(日) 19:27:00.60

そのぶんリソースバカ食いのクソアプリの出来上がり

**デフォルトの名無しさん** · 2024/12/09(月) 00:32:52.38

根っこに流れる考えは、コマンドラインシェルでコマンドをパイプで繋いでいくことと同じだけどね。

一連のワークフローを一つのコマンドとみなして、さらに大きなワークフローに組み込むところとかもね。

**デフォルトの名無しさん** · 2024/12/19(木) 14:37:51.32

F#で遊んだ時シェルのパイプじゃんとは思ってた
関数型言語の原点てシェルスクリプトなんか？

**デフォルトの名無しさん** · 2024/12/20(金) 12:36:38.38

>>233
そこで遅延評価ですよ

**デフォルトの名無しさん** · 2024/12/20(金) 13:57:42.11

>>236
やってから言え
遅延評価こそリソースバカ食いだ

**デフォルトの名無しさん** · 2024/12/20(金) 18:04:51.42

>>237
今の時代リソースなど死ぬほどあるのだよ
自作でサーバー組み立てる場合でもメモリ64Gなんて普通だし

**デフォルトの名無しさん** · 2024/12/20(金) 18:26:08.17

>>238
それはお前の作ってるものがしょぼいからだよ

**デフォルトの名無しさん** · 2024/12/20(金) 18:34:22.69

クラウドはリソース使えば使うだけ課金

**デフォルトの名無しさん** · 2024/12/20(金) 19:25:56.31

遅延評価がリソース食うっていつの時代よ？
むしろ今は遅延評価しないとリソースをバカ喰いする時代だぞ
キャッシュと勘違いしてない？
ディープラーニングとか全部遅延評価だ
それこそ>>239の作ってるものがしょぼいという証明になったな

**デフォルトの名無しさん** · 2024/12/20(金) 19:31:24.56

>>241
多分Haskellの遅延評価のことを言ってるのでは？
メモリをドカ食いすると聞いたことがある
しかしそれは言語のインプリメンテーションやデータ構造の問題であり
一般的な遅延評価がメモリをくうわけではないのよな

**デフォルトの名無しさん** · 2024/12/20(金) 20:48:35.33

>>241
だからやってから言えって
Haskellの不評のひとつが遅延評価だ

**デフォルトの名無しさん** · 2024/12/20(金) 21:17:48.55

Haskell使いは大変でちゅね～

**デフォルトの名無しさん** · 2024/12/20(金) 22:16:28.31

遅延評価だからリソースバカ喰いするわけじゃないのにね
バカは因果関係がわからないからな

**デフォルトの名無しさん** · 2024/12/20(金) 22:30:04.43

Haskellしか書いてないんじゃないの？
知らんけど

**デフォルトの名無しさん** · 2024/12/21(土) 17:16:28.03

ひぐちデブすぎんか？