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

アラタナエンジニアブログ

aratana Engineer's Blog

僕らの継続的ビール摂取型ドメイン駆動設計(ChatWork ✕ アラタナ合同勉強会)

f:id:issei-homan:20150702183328p:plain


アラタナの増田です。
先日の「僕らの Scala + ドメイン駆動設計(DDD)はじまった宣言」から1ヶ月。
アラタナでは、さっそく「はじまった宣言」の内容を実践すべく様々な取り組みを始めました。
今回は、その中でもドメイン駆動設計(以下、DDD)について取り上げます。

(追記)ChatWorkさんも当日の様子を記事にしてくださいました!
(DDD×Scala)×(ChatWork×アラタナ) 合同プログラミング勉強会レポート!!

ChatWork ✕ アラタナ 合同勉強会

新しいメンバー構成、新しい言語、新しい設計手法でのスタートなので、毎日が学びの連続で試行錯誤しています。特にDDDについては今後とても大切な設計思想となるので、Scalaよりも優先的に学習を開始しました。最初に概要を掴むために「Domain Driven Design(ドメイン駆動設計) Quickly 日本語版」をデザイナーなど含めて読み合わせた後、あとはエンジニアメンバー全員でDDD本(おもに『エリック・エヴァンスのドメイン駆動設計』)を一気に読破し、毎日みんなで解釈をレビューしながら最後に初めてのモデリング練習を行いました。現在ではScalaのコードを書きながら毎日実践をしていますが、自在に使いこなせるところには至っていません。

そこで今回、すでに1年前からScala + DDDでの開発スタイルに転換されているChatWorkさんの知見をうかがうべく、合同勉強会という形でワークショップを開催しました。
ChatWorkさんのDDDへの取り組みや、Scala採用に至った経緯などについてはブログでも公開されており、アラタナでも以前から参考にさせていただいていました。

しかもいまChatWorkさんには、DDDの第一人者として有名な、かとじゅんさんこと加藤潤一さんがいらっしゃる・・・・。
これはもう、、、

乗るしかないこのビッグウェーブに!!

f:id:aratanakoho:20160801135929j:plain

ということになるわけです。こんなノリの図々しいお願いにも関わらず共催を快諾してくださったChatWorkのみなさま、ありがとうございます!!


また、両社初顔合わせとなるメンバーも多かったことから、堅苦しい感じではなく食べ飲みながらやろう!というのが勉強会の内容より先に決まっていて、 オフィスや飲み物までご用意いただきました。重ね重ねありがとうございますm(_ _)m


ワークの内容

勉強会に参加したメンバーはエンジニアが中心ですが、東京では非エンジニアやデザイナーも含まれていました。こうしたChatWorkさん、アラタナの混成メンバーを4〜5人のチームに分けて、1時間のモデリングワークに取り組みます。非エンジニアがいることから、今回の目的にはモデリングそのもの結果より、ユビキタス言語で概念を捉えてコミュニケーションすることの大切さを改めて実感しよう!ということを意識して取り組みました。

ワークのお題は、「図書館の本貸出サービス」をモデル化すること。
f:id:masuda-aratana:20150701152844p:plain

ワークの観点としては、

  • 図書館システムの機能を実現できるモデルを定義することができるか。
  • 制約事項を適切に表現することができるか。
  • エンジニアでないメンバーも含まれる中、ユビキタス言語を構築しながらコミュニケーションできるか。
  • 効果的かつ継続的にアルコールを摂取しながら、勢いでなんとかすることができるか。

の4点がポイントになります。

モデリング実践!

ということで、さっそく実践です!
f:id:masuda-aratana:20150701185954j:plain

まずは、キーになりそうな名詞に着目しました。「図書」「利用者」「貸出」「返却」「予約」など、着目した名詞を付箋に書いて、模造紙にどんどん貼り付けていきます。こうしていくことで、エンティティの候補になりそうな名詞をピックアップしていきます。かとじゅんさんからも同様のアドバイスが飛びます。

今回の図書館システムの一番の目的は何かというのを考えて、その目的に沿った一番重要なモデルは何かということを優先順位を付けながら考えていくと、議論しやすいと思います。まずは独立したエンティティをどう見つけるか。わかっている情報から名詞を抽出してみて、特に大事だと思うものをモデルの候補としてみてください。

f:id:masuda-aratana:20150701184155j:plain


図書館システムを対象としているので、「図書」から着目したチームが多く見られました。ですが、ひとえに「図書」といっても、下記のように各チームの論点はさまざまでした。

  • 図書」でもいいんだけど、設計においては「本」と表現しませんか。
  • 図書」が貸出中かどうかの状態をどう表現しましょうか。
  • 図書」を識別する情報は、「図書名」だけで十分だろうか。
  • 図書」は「書籍」と「雑誌」に区分されるみたいだけど、「書籍」と「雑誌」では振る舞いにどんな違いがあるか。
  • 図書」に対して「著者」が紐づくと考えたとき、「著者」は独立して存在するというよりは「図書」の集約の概念に入れて考えるべきだろう。

f:id:masuda-aratana:20150701174335j:plain



図書」を中心に議論を組み立てていくにつれて、あるチームでは「本棚」に話が及びました。
この「本棚」については、順調かつ継続的にハイボールを摂取されていたかとじゅんさんから的確なツッコミが。

f:id:masuda-aratana:20150701174420j:plain

「本棚」を考えたときに、本を保管する役割が当然あると思います。
でも、ユースケースを考えて、本を保管する場所って本棚だけだっけ?ということを議論しないといけない。本は本棚に置かれるだろうけど、倉庫の裏にも保管されてるし、返却されたばかりの本はカウンターに置かれるだろうし。それを、「本棚」だけで考えて本当に業務が成り立つのか、問題が解決できるのか。
本が保管されているのが本棚に限らないのであれば、「保管場所」っていう概念が必要になってくる。そう考えると、「本棚」という呼び方はモデルとしては相応しくなくて、「保管場所」みたいな名前の付け方が適切になってくる。

ツッコミの内容もハイボールの摂取間隔もさすがです。
要所でこうしたツッコミやアドバイスを入れていただくと、論点が明確になったり、自然と議論が深まります。DDDやモデリングに不慣れなメンバーが多い中、エキスパートによる支援の効果を実感することができました。

f:id:issei-homan:20150702111249p:plain
東京チームの様子

f:id:issei-homan:20150702111242p:plain
宮崎チームの様子


結果発表

1時間という制限時間のなかで、それぞれのチームなりのモデルをアウトプットしました。
なかなか短い時間のなかで納得のいくモデルにたどり着くことは難しかったですが、各チーム、特色のあるモデルが発表されました。全5チームの結果を見比べてみたときに、どれも同じようなモデルにならなかったというのは興味深いポイントでした。

  • 1チーム:本が貸出中かどうかという状態を、「利用状況」というモデルで表現したチーム。「利用状況」には、「貸出履歴」「返却履歴」があり、貸出、返却というアクションごとに履歴が積み上がっていく。
  • 2チーム:.今回の目的は本の貸出状況を管理することであって、目録に新着図書を加えたり、既存の本を廃棄することは知ったことではない!コンテキスト外なんだ!!と男らしく割り切ったチーム。「今」モデルという謎のモデルが登場するなど、いろいろ斬新。
  • 3チーム:多くのチームが本に「冊数」「蔵書数」という属性を持たせる中、唯一、「在庫」モデルを定義したチーム。「在庫」というエンティティがあったほうが、同じ本であったとしてもどの本を誰が借りているのか識別しやすいのではないか。また、「WEBシステムというよりリアルの図書館の窓口での貸し出しシステム」を想定し、「本棚から窓口に行くまでの間、利用者が本をもって移動してたら、いわゆるロック状態?」など、議論が深まった。
  • 4チーム:モデルとして取り扱うかどうか、「迷ったら捨てる!」というスタンスでシンプルにモデリングした円満チーム。スモールな状態を保つために、必要性を認識するまでは無理に扱わないという判断。とはいえ、他チームよりも網羅的に課題を吸収している。
  • 5チーム:本の識別子として「ISBN」に着目したチーム。同名の本が複数あったとしても、それらを区別する必要はないと判断して、ISBNをユニークIDとして利用。

かとじゅんさんの独断判定の結果、アラタナ@宮崎本社からリモートで参加していた 4チームが優秀賞となりました!
DDD本を読破した効果なのか、乾杯前からビールを流し込んでいた効果なのか。おめでとうございます!!


まとめ

個人的な感想になりますが、ワークの観点に沿って振り返ってみます。

よかったこと

  • エンジニアだけじゃないチーム編成のなかで、お互いの理解が食い違わないような議論の進め方ができたと思います。ユビキタス言語を活用しようとする意識は高かったのではないでしょうか。
  • 各チームの結果を互いに見比べることで、同じ課題であっても多様なモデルが考えられることが実感できました。今回のワークでは、どれが正解かというよりは、どんな議論がなされたか、メンバーの考えがモデルに反映されているか、が大事だったように思いました。
  • ワークや、ワーク後のフリータイムを含めて、DDDについての意見交換できました。モデルの粒度やコンテキストの切り分けなど、宮崎ではなかなか意見をうかがえるような機会がありませんので、参考になりました。
  • いろんな解釈があるので、コミュニケーション大事。一度に質を高めようとだらだら長くするよりも、一旦時間を区切りながら他チームと意見交換して何回も繰り返していくことの方が身になりそうな感触がありました。

反省点

  • 制約事項や集約についてまでは議論することができなかった。このあたり、もっとモデリングの経験を積んで、設計に落とし込めるようにする必要があります。
  • ChatWorkさんからも同様のご指摘が挙がっていましたが、どんな成果物を出すべきか、目指す姿が事前にサンプル提示されていたら、よりスムーズに取り掛かれたかもしれません。
  • 意外とワークに集中してしまった結果、アルコールの摂取をおろそかにするメンバーが続出!


今回の勉強会後、アラタナではモデリングのスキルを向上させるために次の勉強会準備に取り掛かりました。特に、若いメンバーの動きが活発です。今回の合同勉強会の準備にしてもそうだったのですが、若手社員がチームをガンガン引っ張っている姿が頼もしく見えます!


最後になりますが、お忙しいなか今回の合同勉強会を共催していただいたChatWorkさん、ありがとうございました!勉強会後の懇親会でも貴重なご意見、お話をうかがうことができました。メンバー一同、心より感謝申し上げます。

f:id:masuda-aratana:20150702015326j:plain