ドメイン駆動設計：４つのアンチパターン | システム設計日記

６月２３日（土）午後、大阪で、ドメイン駆動設計について、しゃべる予定。 第47回 SEA関西プロセス分科会のご案内 紹介の紹介の紹介、みたいな不思議なつながりで、講演の依頼があった。 「ドメイン駆動設計」を監訳された今関さんも参加いただける。 土曜の午後なので、時間が多め。 一方的にしゃべって終わりではなく、今関さんも交え参加者で、いろいろ話す時間を一時間以上とってもらいました（さらに懇親会もゆっくりと）。とても楽しみなイベントです。 ドメイン駆動設計は、訳本がでてから、あちこちで勉強会や読書会が開かれているようだし、ドメイン駆動設計に興味持ったり、現場で取り組む人が、すごく増えた気がしている。 ネットで流れる情報も「ドメイン駆動ってなんぞや？」的なものだけでなく「私は、こう理解している、やっている」的なものが多くなったんじゃないかなあ。 訳本の威力は絶大。 さて、講演の準備は、いつものよ

[ghostbass]

では、承認ボタンの例だとどのようにすればいいのか。domainが「承認できるか」を提供し、Vがそれを利用する？

[innx_hidenori]

id:k-holy 業務判断そのものがUI側にあるのがダメという意味で、その判定を利用するコードはUIにあってもよいと思います。またURL等はアプリケーション層のものなのでドメイン層には置かないと思います。

[k-holy]

"UI に、業務判断の if 文がある"のところはどういう実装が理想なんだろう。ドメインオブジェクトがボタンのURLを返すとかじゃないよね…

[takopons]

DDDのアンチパターン。

[yujiorama]

ゆっくりと死んでいくのを止められないんだがどうすれば…

[masamkur]

DD

[JHashimoto]

"ドメイン層のオブジェクトが、こういう知識・判断力を持つべき。 そして、ＵＩやＳＱＬ文で、この業務知識を利用するなら、業務判断能力があるドメインオブジェクトから、判断結果をもらうようにする。"

[suginoy]

「私の場合は、原書と格闘しながらドメイン駆動設計の実践のチャレンジを、２年くらいたったある日、若手の書いたコードとモデルをレビューしていた時に、とつぜん、この発想が変わったのを覚えている。」