読者です 読者をやめる 読者になる 読者になる

はむはむエンジニアぶろぐ

このブログのコンセプトは"ハッキングの為なら愛する家族を傷つけることをいとわない" 自分にとってエンジニアリングは "手段ではなく生きる目的" である

再演 リレーションシップ駆動要件分析 ☓ ドメイン駆動設計 ☓ アジャイル開発に参加してきた

勉強会 DDD

ギルドワークスさんで開催された 再演 リレーションシップ駆動要件分析 ☓ ドメイン駆動設計 ☓ アジャイル開発 に行ってきた。
発表された資料は、勉強会のリンク先にあります。

感想と質問したことをまとめておく。

RDRA for 越境アジャイル

到着が遅れたので、RDRA for 越境アジャイルから参加しました。
顧客やチームメンバーとコミュニケーションを円滑にするためモデルをどうやって表現するか?
話されていたことは理解できるし、現場で似たようなアプローチはしている。
でも、チームがモデルを共有できる状態になっていないし、まだまだ良くしていける余地はあるので以下の書籍を参考にしてみよう。

実は読んだことあるんだけど、活用できていない。
今日の話を聞いてもう一度読んでみる。

RDRA DDD Agile

改めて、日々開発メンバーや関係者と話し合うことは大事だなと思わされた。
スピーディーで新機能をバンバン作る現場なので、なかなかこういう話ができていない。
チームの趣味趣向もあるので、難しいなと思うこの頃。

増田さんにDDDについて質問してみた。
とても、参考になりました。
ありがとうございます!!

setter/getter禁止について

Q. setter禁止は、納得できるがときにはgetterも必要ではないか?DBへのストア時など。
A. getter禁止とは、getしてifなどのロジックを書くなという意味である。
getしてそのまま扱う分に関しては構わない。
ダイレクトフィールドアクセスなどを使うと、getterはいらなくなる。
http://image.slidesharecdn.com/domain-objects-160525131742/95/-61-638.jpg?cb=1464182380

toJson/toXmlメソッドについて

Q. ドメインオブジェクトのJSON表現が欲しい場合、getterをつけてロジックをっくのではなくtoJsonを実装するのが、DDDっぽいと思っている。
しかし、XML表現が欲しくなった場合、開放閉鎖原則に反することにならないか?
なにか、うまいやり方はあるのか?
A. ドメインオブジェクトにtoJson/toXmlメソッドは作らない。
ViewクラスでJSONなりXMLにせよ。
Viewクラスのコンストラクタにドメインオブジェクトを渡し、JSONなりにする。