ドメイン駆動設計を理解する３つのキーワード - ソフトウェア設計を考える

ドメイン駆動設計との出会い １０年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。 あまり、面白いとも思わなかった。 当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリング本を参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。 それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。 どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。 バグとの格闘の中で、リファクタリング（設計改善）の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを

[j5ik2o]

“さらに多くの学びができそうな予感にわくわくしている” 素晴らしい

[knakamura1977]

DDDを現場で実践し続けて、ご自身の知見をブラッシュアップし続けているのがすごい。

[takatama]

DDDは「サービス専用の電卓」をつくるための道具。ビジネスルールと型は、電卓に与えるルール集

[a_suenami]

増田さん、オブジェクト指向の人のイメージ強いですが、先日話したときHaskellのmoduleの考え方に影響受けているようで、この記事はそれをよく象徴していますね"データの記録と参照とは分離された、純粋な「計算モデル」"

[ackintosh]

僕が静的型付け言語にキャリアチェンジした理由はこれでした. "計算モデルの表現技法として、型指向のプログラミングがぴったりというわけだ"

[nyop]

このレベルの概念はビジネスの理解と表現というところでSAPと非常に親和性のある話だと思うんだけど、日本のSAP界隈だとあまり触れられないのが寂しさ。

[hi-hats]

“集約（アグリゲート）はデータの集約ではなく、「計算の集約」を表現する手段だということだ。集約が維持するのは、データベース上のデータの整合性ではなく、計算の整合性であり一貫性ということだ”

[bufferings]

本を読もうと思った。

[kencharos]

わかりやすい。型指向の計算ルールという話だと最近はFPもありだと思うんだよね。今リバイスされたらどういう風になるんだろうか。

[mizoguche]

“価格計算とか日付計算がともなうビジネスルールでは、型指向のプログラミングで記述することで、ロジックを一か所にまとめてわかりやすく整理できる”

[takets]

ドメインモデル＝計算モデルとするモデリングはしっくりくる

[luccafort]

エリック・エヴァンスのDDD本、ようやく8割5分くらいまで読んでもう一息というところなんだけど全く何言ってるかわからんという気持ちでいっぱいです。

[turanukimaru]

集約と永続化を理解正しくするには同一性と連続性の理解が必要なのだが日本の教育には含まれてないから誰も理解できないしもう捨てても良いかなとは思う。クラスは型と型への操作の集合であるところからやり直したい

[yojik]

この表現すごく良い！！ "「ドメインモデル」は、なんらかのルールに基づいた「計算と判定のモデル」ととらえると、だいぶすっきりする。"

[mather314]

「ビジネスルール」「計算モデル」「型指向のプログラミング」

[NetPenguin]

良記事