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

"ぐるぐるDDD/Scrum#2"参加して来ました。

event agile scrum ddd oop modeling

掲題のワークショップに参加してきました。

http://dddscrum.doorkeeper.jp/events/5070

主催者は原田さんです。

https://twitter.com/haradakiro

使用していた(と思われる)スライドです。

http://www.slideshare.net/kiroh/scrum-andddd-tdc2013distss

会場は株式会社エムティーアイ様にご用意頂きました。

http://www.mti.co.jp/?page_id=102

自分の関連記事

http://jumperson.hatenablog.com/entry/2013/04/29/120155

 

ぐるぐるDDD/Scrumは2回目の参加となりました。

1回目参加後、業務でモデルを書いてみたのですが、ER図と同じようになってしまい、これでいいのかともやもやした気持ちを持って参加させて頂きました。

今回は駐車場ドメインのモデルを書くワークショップを1回1時間で、計2回行いました。

 

ワークショップの内容を簡単に紹介します。

今回のドメインの駐車場ですが、有人・無人、有料・無料、ゲートあり・なしなど、様々なタイプの駐車場があります。

その中でモデル化する駐車場を決め、シナリオを書き、それを表現するモデルを書き、TDDでコードを書いて実装できることを確認していきました。

実装できることを確認したらシナリオを追加してモデルをいじめていき、また同じサイクルを回していきました。

2回目のワークでは対象の駐車場を変え、1からシナリオを書き、新しいモデルを書いて、同じサイクルを回しました。

最後に、1回目と2回目のモデルを統合できないか検討しました。

今回は2回目のワークで1回目のモデルは使用しませんでしたが、1回目のモデルに修正を加えていくアプローチもあるようです。

 

このようなワークの中や休憩時間の雑談の中でいろいろな発見がありました。

自分の備忘録的な意味合いが強いですが、新たな気付きを下記に記します。

※DDD/Scrumと関係ない事も含んでいます

 

◆ドメインとは何か?

"ドメイン=感心事"。感心事の中に課題がある。

 

◆ScrumはSmallTalkの技術要素が含まれたプラクティスだった。

現在、一般化されているScrumには技術要素はありませんが、元々Scrumで行なっていた開発チームにはSmallTalkの技術要素が含まれていたようです。

Scrumでやるなら(継続的にプログラムに変更を加えていくなら)オブジェクト指向は欠かせないようです。特に、OCPの原則は必ず守るようにとの事です。

 

◆モデルにはpropertyはあまり書かずmethod中心に書く。

クラスへのproperty追加は簡単だが、変更や削除は難しいとの事です。

ユーザが求めるpropertyがなくても業務が回ることはよくあるので、本当に業務が回らないようであれば追加すればいいそうです。

 

◆REAモデル

すべての経済活動はREAモデルで表現されているようです。

ただし、REAモデルでは抽象的過ぎるため、実装はとても難しいようです。

 

◆DCIアーキテクチャ

オブジェクト指向とは異なるアプローチとして"DCIアーキテクチャ"というアプローチがあるようです。

初めて耳にした単語だったので調べてみましたが詳細がわからなかったため紹介までとしておきます。

 

◆ホワイトボードを持ち歩きたい!という方へ"欧文印刷"

欧文印刷社の"消せる紙"が接着性、書き心地、消し安さ、コスパを考えていると非常に優れているらしいです。

http://www.obun.jp/original/keserushi_white/

紙製のホワイトボード 消せる紙 A3判 (8枚入り)

紙製のホワイトボード 消せる紙 A3判 (8枚入り)

 

◆RedにしないTDDのスタイル。

Redにせずにリファクタリングを行うスタイルのTDDがあるようです。

具体的には古いコードをコメントアウト等で残したまま新しいコードを追加します。その後古いコードを使っている箇所をすべて新しいコードが使うように変更し、テストを実行します。結果がグリーンであれば、古いコードを削除します。

 

◆モデルも慣れれば早く書けるようになる。

モデルもコードと同じで、慣れていけば早く書けるようになるそうです。

業務にかぎらず、日常生活の中で実践あるのみです。

 

◆モデル図がER図のようになってしまってもよい。

ER図と同じようになることに問題はないようですが、propertyではなくmethod(振る舞い)を中心に描くことが大切だそうです。

 

最後に。

前回同様、非常に刺激的で有意義な時間を過ごさせて頂きました。

前回参加後に業務で書いたモデルが失敗した要因はモデルのpropertyを意識し過ぎた事だと気付けたことが一番の収穫です。

今のお客様に限るのかもしれませんが、Enterpriseのお客様は必要なpropertyを中心に要望を上げてくることが多いように思います。

ただ、あまり綺麗なモデルではなかったかもしれませんが、お客様の要望を逐一取り入れていく中で「このモデルで実現できるか?」を考え、できなければモデルに修正を加えていくアプトローチを取ることで、実装イメージが素早く作れ、お客様へのフィードバックのスピードも早くなったように感じています。

  

イベントを開催してくださった原田さん。会場をお貸し頂いた株式会社エムティーアイ様。

その他、協力していただいた多くの方々に感謝いたします。