ビッグローブ × DDD 〜ドメイン駆動設計の現場〜(2015/6/18) #devlove

Takehiro Inoue @i_takehiro

大西さん：もう一度失敗すると、DDD導入活動が白紙になりかねないので、退路を断つ #devlove

Naofumi Yasuba @nyasba

新旧アーキテクチャは別チームで始めたが失敗。混合チームにして再チャレンジ　#devlove

Naofumi Yasuba @nyasba

ユースケースは「処理の流れ」と「責務」が分かる程度に #devlove

Naofumi Yasuba @nyasba

リリース後も1ヶ月はリファクタリング　#devlove

Takehiro Inoue @i_takehiro

大西さん：DDD経験の無い旧アーキテクチャチームへのDDDへ伝えるには、早い段階でコードを共有することで実現。 #devlove

Takehiro Inoue @i_takehiro

大西さん：DDD導入による変化。業務ロジックを全員が理解しないと設計ができないので、上流設計は全員で実施。 #devlove

Takehiro Inoue @i_takehiro

大西さん：リリースに成功したことでDDDの全社展開が決定。 #devlove

Takehiro Inoue @i_takehiro

西さん：実践編。DDDを適用するサービスの決定。 #devlove

Naofumi Yasuba @nyasba

業務知識をドキュメントじゃなくコードにためる。#devlove

flowz @flowzong

"DDD の利点 変更コストを下げる 業務知識をコードにためる" #devlove

Naofumi Yasuba @nyasba

エンジニアの意識を「業務」に向けるの大事ですね #devlove

Takehiro Inoue @i_takehiro

西さん：DDDはコストが高いので、それに見合うサービスを選択する必要があった。 #devlove

Naofumi Yasuba @nyasba

プロセスではなく「考え方」を変えたかった #devlove

Takehiro Inoue @i_takehiro

西さん：DDD専用チームを立ち上げた。#devlove

Naofumi Yasuba @nyasba

のれんわけでチームをふやしていった #devlove

Takehiro Inoue @i_takehiro

西さん：ドメインモデルの作成。ホワイトシートと付箋を使って、チームメンバー全員で作成（１〜２時間程度） #devlove

flowz @flowzong

"はじめはみんな業務知らないので、パパっとつくる" #devlove

Naofumi Yasuba @nyasba

チームの共通認識を形作るためにまずドメインモデル。初期のモデルは業務知識もないので時間決めてとりあえず作るのが大事。 #devlove

flowz @flowzong

ドメインモデル 636 クラス #devlove

Takehiro Inoue @i_takehiro

西さん：実際にドメインモデルを作成した結果。６３６クラス。１３テーブル。 #devlove

flowz @flowzong

お、astah* っぽい画面 #devlove

flowz @flowzong

クラス図の代わりにスケルトンコード #devlove

Naofumi Yasuba @nyasba

ドメインモデルをスケルトンコードに。コードにして初めて気づくこともある #devlove

Takehiro Inoue @i_takehiro

西さん：実際のコードの作成順。インフラストラクチャ層。Fixture(テストデータ)。アプリケーション層＆ドメイン層。ユーザインタフェース層。 #devlove

Takehiro Inoue @i_takehiro

インフラ層を最初に作るっていうのは意外。うまくいくのかな？ #devlove