FiNC Microservice Meetup のLT

1. LTはじめます！

2. 自己紹介

3. 重村 裕紀
• しげ or げし
• 22歳
• 2016年4月から新卒でFiNCに入社
• Ruby/DDD/SoftwareTest/(Scala)

4. 所属プロジェクト

5. 最初に着手した課題

6. テストを書いているの
にバグを防げない

7. カバレッジは60%あった。

8. 結果テストの正しいやり方
ができていなかった。

9. やったこと
• テストに関するドキュメントを作る
• ハンズオンでテストのやり方を訓練する
• テスト文化を浸透させる

12. すると、巨人の進撃が!?

13. 止まらなかった。

14. 何故か？

15. そもそもプログラム設計の段階でユ
ースケースの抜け漏れが多かった。

16. 仕様
↓
プログラム設計
↓
実装
↓
テスト
仕様を全て満た
せていない。

17. 次に着手した課題

18. 仕様が難解

19. 今までの仕様書
Excel一枚に全てのコンテキストをつめ込まれていた。
-> ユースケースがMECEであるか判断難しい。
-> 前提の抜け漏れ。

20. UI Flows + Gherkin

21. UI Flows
画面遷移が一目でわかる。

22. Gherkin
Feature/When/Given/Thenで仕様記述
ユースケースの網羅性が高まる。
Feature 面談予約
Given ログインしたユーザー
Given アンケートを受けている
When スケジュールを選択
And 予約確定ボタンを押す
Then 予約確定
Given アンケートを受けていない
Then スケジュールを選択できない

23. Gherkin
Feature/When/Given/Thenで仕様記述
ユースケースの網羅性が高まる。
Feature 面談予約
Given ログインしたユーザー
Given アンケートを受けている
When スケジュールを選択
And 予約確定ボタンを押す
Then 予約確定
Given アンケートを受けていない
Then スケジュールを選択できない
ここが抜け漏れ
る。

24. 結果

25. ユースケースの抜け漏
れがかなり減った。

26. 副作用

27. テスト駆動できるよう
になる。

28. 仕様確認のコミュニケー
ションコストも減った。

29. 今度は、巨人の進撃が!?

30. ちょっと止まった。

31. しかし、

32. 諸悪の根源

33. 正体を現し始める。

34. RDB + ORM + MVC
×
大規模アプリケーション

35. = 結構闇

36. 特徴
• テーブルとクラスが一対一
• 基本テーブルは関連を持っている
• Viewにビジネスロジック、ドメインモデルが漏
れだす

37. 問題
• テーブル構造を隠蔽しきれなくなる
• 関連地獄
• ファットモデル
• マイクロサービスに切り出しにくい
• オブジェクトがただのDAO(Data Access Object)

38. DDD
ドメイン駆動設計

39. DDDのメリット
• ビジネスドメインへの理解が深まる。
• ドメインモデルを蒸留させることができる。
• 関連を最小限に抑えることが出来る。
• マイクロサービスと相性が良い。

40. 社内勉強会を開きました。

41. 頑張った甲斐あった

42. やったこと

43. コンテキストマップを作り

44. まだ着手したばかり

45. ありがとうございました
。