【DDD】ドメイン駆動設計【エリック・エヴァンス】
第1部 ドメインモデルを機能させる
ドメイン駆動設計におけるモデルの有用性
ソフトウェアの核心
第1章 知識をかみ砕く
効果的なモデリングの要素
知識のかみ砕き
継続的学習
知識豊富な設計
例1.1——隠された概念を引き出す
深いモデル
第2章 コミュニケーションと言語の使い方
ユビキタス言語（UBIQUITOUS LANGUAGE）
例2.1——貨物輸送プログラムを完成させる
声に出してモデリングする
1つのチームに1つの言語
ドキュメントと図
書かれた設計ドキュメント
実行可能な基盤
説明のためのモデル
例2.2——輸送業務と経路
第3章 モデルと実装を結びつける
モデル駆動設計（MODEL-DRIVEN DESIGN）
モデリングパラダイムとツールによるサポート
例3.1——手続き型からモデル駆動へ
骨格を見せる：なぜモデルがユーザにとって重要なのか？
実践的モデラ（HANDS ON MODELERS） >>175
あんたに限らず関数型が大規模なプログラム書くのに向かないと思ってる層がちゃんと関数型プログラミングをしたことがなく先入観でもの言ってるのはよくわかった >>176
あんたも決めつけで言ってるだけだろ
関数型で状態遷移を把握しづらいのは
強く実感しているし普及しない原因だ >>177
それはどの言語でどんなことしようとして「強く実感」したの？
関数型言語が普及しないのは、単に先入観やOOP神話の影響で学ぼう使おうと思う人が少ないからだよ。
関数型プログラミングが普及しない理由は、当然だが関数型プログラミングの諸概念を表現するのに命令型言語が不向きだから。柔道着着て水泳するようなもんだ。 一昔前のOOP厨と一緒だな。
歴史を学ばん奴は一生ループする。 >>179 そうだよなと得心する事が多くて良い資料ですね
ドメインに継承や移譲が要るって考えてる人は是非とも読んで欲しいし、反例を挙げて欲しくなる >>179
俺もこのスライドの作成者の本で関数型DDDに入門したクチだけど、本当にわかりやすかった
もともとHaskell, purescriptはやってて関数型には慣れてたけど、
DDDについては知らなかったので、せっかくだから関数型前提で書かれている本でと手にした。
Domain modeling made functional っていう本で、
DDDの解説はもちろん、関数型プログラミングの諸概念の解説もわかりやすく、
一冊で二度美味しい内容で、実用的な関数型プログラミングの入門書としても超おすすめ。
https://youtu.be/dEKvIxsERAI
ちなみにyoutubeにはこのスライドの発表動画もあったりする Matthias Felleisenの「How to Design Programs」を読んで関数型プログラミングに
興味を持ったものです。
次にモナドを勉強しようとしてHaskellの本を読んだがいまいちピンときません。
>>182さんが挙げられている本では、モナドを使ってモデルの実装をしているようですが、
モナドの使い方は理解できますか？ Scalaで良ければ、manning.comからでてる Functional and Reactive Domain Modeling にモナドでドメインサービス組み立てる話が掲載されてる。
なおFree Monadをベースとしているので軽く死ねる。
https://www.manning.com/books/functional-and-reactive-domain-modeling >>184
ありがとうございます・・・でもDomain modeling made functional をPDFでポチっちゃいました。
後で読もうと思います。
ところでDDDを学ぶ上で、大規模な開発経験が必要なんでしょうか？
自分は学生で、そのような経験がありません。
『How to Design Programs』では小さなプログラム作成の演習はありましたが、
それ以上の大きさのプログラム作成の方法はありませんでした。
DDDは大きなプログラムをつくるガイドになりますか？ >>184
これ読んでみようかと思ったら
＞読者は関数型言語とドメイン駆動設計に慣れている必要がある
とあるんだが、読むのにドメイン駆動設計の深ーい知識は必要だった？ >>187
必要最小限ではあるがScalaの文法解説と、各ドメインオブジェクトの解説は入っていたはず。
知っていれば理解が進みやすいくらいに考えてればいいはず。 DDDもそろそろバージョンアップせんと
OOPは時代遅れ Freeモナドなんて言語埋め込みDSLを作るってだけ DDDいいよね！
なんちゃってOOPから脱出する際に役立ったよ DDD、CQRS、イベントソーシング…
企業内システムでここまでやってるとこってあるんだろうか
参照系中心のシステムでDDDやるのは愚行？ おれはさとった
名前がちがうだけのValueObjectクラスだけつくって
メソッド引数の位置を間違えられないようにしときゃいいんだ
それだけでいいんだ
バリデーションは入り口でやる
中は値が正しい前提でまったくチェック不要
それがDDD それだけでDDDは語れないような…
いまだに集約がわからんよ 教科書が概念的でよくわからんことばっかほざいてる時点でおかしい
サンプルを一発提示すればああこんなのねって
それで終わるだろ！？ ガサッと取ってきて変更して全部更新！ってアホなんって思った
これの何がいいの？ >>197
2003年頃ならともかく。OSSのアプリが溢れている今の状況ならこのアプリのこの部分はこのパターンを使っているって示せると思う。 >>191
亀レスだが、OOPを補完するのがDDDだろうに
なんでDDDスレでOOPが時代遅れだと言えるのか疑問 >>201
OOPより上位レイヤーの概念なのでOOPを補完するものではないよ
Eric Evansの最初の本ではDDDの実装例としてOOPが使われただけ
関数型で実装する例もある >>202
> OOPより上位レイヤーの概念なので
> Eric Evansの最初の本ではDDDの実装例としてOOPが使われた
そういうのを補完って言うのでは？ >>203
お前は国語から勉強し直さないとこの先辛いぞ？
お前は概念とか言ってる場合じゃない ほかん
【補完】
《名・ス他》
足りない点を補って完全にすること。
OOPに足りない部分をDDDで補ってるって言いたかったのでは？
別に変だとは思えないけど OOPを補完するのがプログラミングだろうに
なんでプログラミングスレでOOPが時代遅れだと言えるのか疑問
OOPに足りない部分をプログラミングで補ってるって言いたかったのでは？ OOPはプログラミングを補うものでありプログラミングがOOPを補う訳ではない >>205
補完などではない
そもそもOOPなどと書くから話がおかしくなる
DDDはOODを包含した概念である OODと言い換えたところで補完もしてなければ包含もしてない
DDDをOOの文脈でしか理解できない人は抽象概念の理解がもともと不得意なのか
日本人の書いたなんちゃってDDD本で分かったつもりになってるか
そもそもOO以外を知らないか お前はDDDを学んでもOOP及びOODには何の影響もないみたいだけど、俺は別にDDDで学んだ知識がOOP／OODに役立ってるので、別にどうでもいいっす。
なんで役立ったのか想像できないのなら、その程度ってことでしょう。 OOPにありがちな、車やエンジンを例にした説明より
DDDの方がしっくりくるというか
あ、OOPでこんなことができるのかと目から鱗だったな いつの時代になってもITの方法論は「方法論オナニストに都合のよい飯の種」の域を出ない 建設業のように国が規格を決めてしまえばよかったんだ
国所属の認定団体に承認された関数以外使ってはいけません DDDとは、「ドメイン知識(モデル)」を「駆動」して「開発」する開発手法であって、何か特定のアーキテクチャをあらわすものではない 嘘言いました
最後のDはDevelopmentじゃなくてDesignだったわ
恥ずかしー 設計はアーキテクチャを示すものじゃない
言葉が違えば意味が違う DDDは大量データ更新に弱い
10万件のレコードに同じ値をセットする処理に途方もなく時間がかかる カルト宗教だよね
設計というのはパフォーマンス要件の整理と実現に当たってのアーキテクチャを考えるために必要なわけで
機能要件にSLAがないだなんてことは設計するならばありえないし、
じゃあその要件に到達するためにシステムやミドルウェアをどう使っていくかがアーキテクトの肝なところじゃん
APPサーバに閉じた議論しかしてない時点で雑魚システムしか作れんし
雑魚システムにそもそも設計なんざいらんだろって話よ
こういう連中が言い出しそうなこと、DBは抽象化できる
そもそもファイルを保存するならテキストでもいい
依存性の逆転を駆使すればインタフェースに依存させることができるので、アプリから実装詳細が消える！
それでDBがやってくれてるトランザクション制御や成約、整合性の解決を
ファイルシステムで実装するその実装を誰が書くの？
アーキテクトを自称するなら君が書くってことだけど、いったい誰がそんなこと頼んだんだろう 型システムの理解も貧弱、DBMSの理解も貧弱、なんならネットワーク・プロトコルの理解も貧弱
一生システム完成させる気ないやる気なしエンジニアの最後の拠り所だろ ｺﾞｼｺﾞｼ(-_＼)(/_-)三( ﾟДﾟ) ｽ､ｽｹﾞｰ! 
