ビッグローブ × DDD〜ドメイン駆動設計の現場〜ファーストサービスのリリースまでの活動

自己紹介氏名 大西 真央（@mmmmao0530）

組織としての役割 DDD布教活動

チームとしての役割 リードエンジニア（技術リーダー）

最近の関心ごと ・効果的なドメインモデル作成

・チームビルディング

太陽系戦略

Wifi

０A0

モバイルコラボ関連会員

VAS特典

商品契約

トリトン

冥王星海王星土星

木星

火星地球

ドメイン駆動設計の拡大

認証

金星

第二世代

時間軸：2年

今回話すところ

アジェンダ① ファーストリリースまでの道のり

② DDD導入後の変化・成果

ファーストリリースまでの道のり

概略

2013/06 2014/02

①DDD手法の模索

増田さんDDD導入支援として、外部講師を呼んで

週1回くらいのペースで、支援してもらった。

DDDのコンセプトを説明

具体的なDDDの進め方を説明

ドメインモデル・コードのレビュー

実践の場

２０１３年２Qに新サービスが開始予定

新旧のアーキテクチャで平行開発あわよくば、新でリリースする（はずだった）

新サービスの内容

新サービスの仕様 その①① 「BIGLOBE LTE・3G」もしくは「BIGLOBE 3G」の契約者が利用可能。

② 利用する端末のMacアドレスの登録・変更・削除の管理が可能。

③ 「BIGLOBE LTE・3G」もしくは「BIGLOBE 3G」を解約すると、連動して対象のMacアドレスも削除。

④ Macアドレスの変更可能回数は月２回まで（同月内の削除⇒登録も変更とみなす）

新サービスの仕様⑤ 登録できるMacアドレス数は、 「BIGLOBE LTE・3G」もしくは「BIGLOBE

3G」の料金プランによって異なる。

⑥ 登録されたMacアドレスで、WiFiを利用可能にする。

⑦ WiFi利用実績が９０日間なければ、Macアドレスが削除。

開発チームの編成

新アーキテクチャチーム 旧アーキテクチャチーム

相互連携

まず、初めにやったこと

守破離の守を実践

Biglobeで作られた初めてのドメインモデルアプリケーション層 ドメイン層 インフラストラクチャ層

今見ると、関連がないのでよくわからないドメインモデル

エンティティとか

値オブジェクト

ドメインモデル⇔コードへ①同じ機能を

個人ごとに開発

②開発チームで

気づきの共有

③個人の開発に

フィードバッグ

④増田さんに

質問・レビュー

⑤作ったやつを壊して

０から開発

意識した点手続き型に縛られないために、オブジェクト指向設計に完全に振り切ってみた。プリミティブな値は、全て値オブジェクトでラッピングGetter・Setter禁止１行につき１ドットまで可能な限りIF文を除外などなど

※オブジェクト指向エクササイズとほぼ同じ考え方を導入。

結果 リリース断念

旧のアーキテクチャを

リリース

アプリケーション

コードが

間に合わず

インフラが

間に合わず

次サービスへの万全の準備リリースできなかったサービスを最後まで完遂(未リリース)

アーキテクチャ全体コンセプトの再整理

アプリケーションから利用されるライブラリの整理

インフラの整備

ビルドツールの変更（MavenからGradle）

②ファーストリリースへ

対象サービス

失敗したWi-Fiスポットに再チャレンジ

旧→新にアーキテクチャをリニューアル

機能強化

を同時に実施。

チーム編成新アーキテクチャチーム：５名 旧アーキテクチャチーム：３名

融合

一つのチーム：８名

１チームにした理由

今回、失敗するとDDD導入活動が白紙になる可能性があったので、自分たちで退路を断った。

僕達の心境・状況

開発したモデル

守破離の破をちょっとだけ実践

ユースケースフロー図

ユースケース記述だと、細かい内容も記述する必要があったので、自分たちのスタイルと不一致

例：ユースケースフロー図

ざっくりとした処理の流れと責務がわかればよい

処理の流れ

アクターアクター

苦労した点①

旧メンバへのDDDの伝え方がわからない旧メンバが不安でいっぱい

早い段階でコード作成して、まずはコードで共有

新アーキテクチャチーム

DDD暦 ６ヶ月旧アーキテクチャチーム

DDD暦 ０ヶ月融合

苦労した点②

新アーキテクチャ

旧アーキテクチャ２０年分の貴重な資産

旧アーキテクチャの資産を有効活用するための腐敗防止層

祝：リリース

約８ヶ月かけてようやくリリース。

リリース後

約１ヶ月間

ドメインモデルから

リファクタリングを実施。

DDD導入後の変化・成果

変化① 上流設計

特定メンバで実施

全員で実施（理由は次のスライド）

変化② 業務

業務を理解しなくても開発可能

業務をコードで表現するため

業務を理解して開発することが必須

変化③ 自動テスト

自動テスト環境がなかった

自動テスト環境整備

変化④ 仕様変更

自動テストがないので、場当たり的な対応のみ

ドメインモデルから見直してベストな設計・実装を模索

変化⑤ 環境

独自言語なので外部から調達不可惰性で開発

成長しないと不要扱いされる危機感も刺激的

成果①

過去何度もトライして、

成功しなかった

旧アーキテクチャからの進化に成功

成果②

DDD全展開 決定

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