Finc microservice meetup_shigemura_lt

LT はじめます！

自己紹介

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

所属プロジェクト

最初に着手した課題

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

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

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

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

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

止まらなかった。

何故か？

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

仕様↓プログラム設計↓実装↓テスト

仕様を全て満たせていない。

次に着手した課題

仕様が難解

今までの仕様書Excel 一枚に全てのコンテキストをつめ込まれていた。

-> ユースケースが MECE であるか判断難しい。-> 前提の抜け漏れ。

UI Flows + Gherkin

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

GherkinFeature/When/Given/Then で仕様記述ユースケースの網羅性が高まる。

Feature 面談予約 Given ログインしたユーザー Given アンケートを受けている When スケジュールを選択 And 予約確定ボタンを押す Then 予約確定 Given アンケートを受けていない Then スケジュールを選択できない

GherkinFeature/When/Given/Then で仕様記述ユースケースの網羅性が高まる。

Feature 面談予約 Given ログインしたユーザー Given アンケートを受けている When スケジュールを選択 And 予約確定ボタンを押す Then 予約確定 Given アンケートを受けていない Then スケジュールを選択できない

ここが抜け漏れる。

結果

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

副作用

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

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

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

ちょっと止まった。

しかし、

諸悪の根源

正体を現し始める。

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

= 結構闇

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

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

DDDドメイン駆動設計

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

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

頑張った甲斐あった

やったこと

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

まだ着手したばかり

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