ULSアジャイル推進室基幹系システムの再構築におけるDDD事例 20160312

ULSCopyright © 2011-2016 UL Systems, Inc. All rights reserved.

Proprietary & Confidential Powered by

いまさらアジャイル巡業 in 広島

事例紹介(基幹系システムの再構築におけるDDD事例)

2016/3/12

ウルシステムズ株式会社http://www.ulsystems.co.jp

mailto:[email protected]

Tel: 03-6220-1420 Fax: 03-6220-1402


Proprietary & Confidential Powered by 1

内容（基幹系システムの再構築におけるDDD事例）

1. プロジェクト紹介

2. Domain-Driven Design 概要

3. 現場から見えてきたもの

4. まとめ

By 発表者：田上悠樹（ウルシステムズ株式会社）

主にエンタープライズ領域畑で設計・開発をやってきました。

現在 DDDと格闘する悶悶とした日々を過ごす。

ULS 2Powered byCopyright © 2011-2016 UL Systems, Inc. All rights reserved.

Proprietary & Confidential

1. プロジェクト紹介



プロジェクト紹介

クライアント

–製造業（自動車メーカー）

業務領域

– SCM 販売領域（需要予測、オーダー管理、生産連携）

ゴール

–世界140ヶ国からのオーダーを本社で一元管理。

– OEM製品も含めたオーダーの一元管理。

経緯・特徴

– Host系やVB系のサイロ型レガシーシステムをJava系システムに集約。

–基幹系でかつ長寿命のシステム。

– DDDを採用しての構築。

技術要素

–開発言語： Java （利用ライブラリ： Spring, JPA, JSF）



プロジェクトのコンテキストマップ

顧客ドメイン

オーダードメイン

製品ドメイン

生産拠点ドメイン

コンテキストマップ

–オーダードメインをコアとし、周辺に顧客、製品、生産拠点のドメインが取り巻く。



2. Domain-Driven Design 概要



DDD（Domain-Driven Design ドメイン駆動設計）の概要

DDDとは

– Eric Evans 氏が提唱しているソフトウェア設計手法。

–機能中心ではなく、『ドメイン（ビジネス上の関心領域）』に設計の

重心を置いたオブジェクト指向設計手法の１つ。

DDDが目指している世界観

–根源的なモチベーションは、副題にある「ソフトウェアの複雑性に立ち向かう」こと。それに向かって様々な設計哲学が登場するが、本日焦点をあてたいポイントはコレ。

『ドメインの隔離』ユビキタス言語

ドメインエキスパートモデル駆動設計

リファクタリング蒸留



DDDの登場人物

- UI層 - - アプリケーション層 -

ドメインの知識を調整しユースケースを実現

- ドメイン層 -

DDDの中心エリア。ビジネスの知識を集約した小中規模の部品群

- インフラストラクチャー層 -

アプリケ｜ションエリア

基盤エリア

Application Service

ドメイン部品を組み合わせて、ユーザーに対して価値のある機能を提供

Domain Service

ビジネス上のポリシー・判断を提供

Value Objectコード数値にビジネス上の意味を与える

Entity単なるTable模写以上のデータ構造体を提供

Repository (impl)

永続化装置とのやりとりを担当

これらの登場人物同士を協調させるためのFactoryやAggregateといった合わせ技も登場。

ユースケースのエリアビジネスロジックのエリア



DDDと他のデザインパターンとの比較

DDDの立ち位置

DDDは特定の業務や設計問題に対して局所的に適用するパターンというよりかは、アプリケーション全体に適用する知識配置のパターン。知識配置に対する言及がMVCほどマクロでなく、GoFほどミクロではなく、その中間に位置する。

但し、上記パターンと対立しているわけではなく、むしろ共存している。DDD本の中にもGoFやAnalysis pattern が登場する。

パターン説明

GoF design pattern

23の設計パターン（Factory Method, Singleton, Strategy, Visitoretc ）をカタログ化したもの。アプリケーション全体に対して適用するというより、設計上の問題が発生している箇所に対して目的別に適用する。

GRASP

責任駆動による設計パターン。疎結合性と高凝縮性を軸に、クラスの責務配置の基本原則をまとめている。情報エキスパート、コントローラー、人工品などのパターンが登場する。DDDの配置と通ずるところがある。

Analysis pattern

エンタープライズ領域に登場する代表的な業務・組織についての概念パターンをまとめたもの。在庫、会計、取引、金融商品などの具体的な業務を題材に、共通の構造を見出してパターン化している。



3. 現場から見えてきたもの

DDDの旨味（総論・各論）

DDDの苦味



DDDの旨味（総論：部品の共有）

部品の共有

– アプリケーション層とドメイン層の間やドメイン間では、オブジェクト同士が1対1ではなく有機的に結びつくので、コミュニケーション図相当のダイアグラムで可視化。

–他の人が作ったドメイン部品を自分が担当しているユースケースにも組み込めるので、ロジック実装の部分をショートカットできる。

オーダー受付

生産拠点ドメイン

製品カタログ表示カレンダー

ドメイン製品

ドメイン

顧客ドメイン

- アプリケーション層 - - ドメイン層 -

オーダードメイン

生産振分け先の決定

オーダーステータスの更新

オーダー可能期間の確認OEM製品判定

注文チャネルの確認



DDDの旨味（総論：システムの成長）

コアドメインをベースにしたシステムの成長

– ドメインが安定してくると、そのドメインを再利用してユースケースの追加・変更が行いやすく拡張しやすい。

–但し、ドメインを安定させるまでは一苦労で、設計と実装の Try&Error の繰り返し。恩恵をあずかれるのは、後半戦から。

ドメインを形作るまで投資が必要。

イテレーティブな日々。

ユースケースを追加しやすく投資を回収できる。

インクリメンタルな日々。

安定期成長期黎明期

コアドメイン

コアドメイン



Value Object

– 『意味有り』コード

意味有りの注文番号や製品コードには、その業務特有の知識が宿っている。その知識の部分をValue Object に集約する。

– 『意味無し』コード

ほとんど知識自体を持たないコードであっても、Value Object として定義すれば、シンボルの役割を発揮する。（メソッド引数がString だらけ、、という状況も解消。）

– コード値に限らず、数値、日付、区分値などをValue Objectにすることで、単なるString やInteger以上の知識を持て、よりセマンティックなプログラムになる。

DDDの旨味（各論：知識の集約 Value Object）

ー JAN企業コード

ー商品アイテムコード

ーチェックデジット

流通システム開発センター: http://www.dsri.jp/jan/about_jan.htm

プログラム中でString janCode;

という単なる文字列ではなくJANCode janCode;

というJANCode本来の意味をオブジェクトで表現する。

JANコードの例)



DDDの旨味（各論：知識の集約 Entity）

Entity

– 『Aggregate』を利用して、複数Entityの知識をモデル構造を保ったまま集約。

– 『Factory』を利用して、イベント毎のEntity生成のロジックを1箇所に集約。

<<Root>>Header

DetailMaster

- Aggregate -- SQL上のJOINだけ -

<<Factory>>

オーダーFactory

新規オーダーのEntityインスタンス

製品を変更したEntityインスタンス

納期を変更したEntityインスタンス

新規オーダーのEventインスタンス

製品変更のEventインスタンス

納期変更のEventインスタンス

引数：戻り値：

関連するEntity同士の構造を保った上でデータアクセスができ、Entityを跨った横断的な知識も提供できる。

どんなに秀逸なERモデルでも、SQL自体の戻りは常に2次元配列。本来のER構造は一時的に失われる。

Entityに復元



DDDの旨味（各論：知識の集約 Service）

Service

– コアドメインである『オーダードメイン』のサービスは、オーダーに関連する複数のドメインの知識を集結させて、初めて『オーダー受付』というユースケースが成り立つ。

–ユースケースはシステムの成長過程で増えていくので、新しいビジネスイベントが生まれてもドメイン部品を組み合わせるだけでスケールできるように構造化した。

イベント検出

新規オーダーイベント

製品変更イベント

納期変更イベント

将来的に発生し得るイベント

顧客ドメイン： ○○判定 ○ × ○ …

製品ドメイン： △△判定 ○ ○ × …

生産拠点ドメイン： □□判定 ○ ○ ○ …

カレンダードメイン： ○○判定 ○ × ○ …

オーダードメイン領域

様々な文脈のオーダー情報

イベント振分け

インクリメンタルに実装



DDDでの性能問題

ドメイン層は中粒・小粒の部品で構成されているため、ときに性能問題が起きやすい。

–相反する課題

–対応した方法

再利用を重視して中粒のクエリを採用した。ただし、クエリキャッシュの機能をインフラストラクチャ層に実装して、I/O回数を減らす施策を実施した。

DDDの苦味（性能問題）

性能・最適化 VS 再利用性

課題A

ある機能に特化したクエリを書くと、性能メリットはあるが再利用しにくい。

課題B

汎用的な中粒のクエリを書くと、再利用性はあるがトータルでI/O回数が増加。

（いわゆる『マシンガンSQL』というアンチパターンになる。）



DDDの苦味（知識の流出）

知識の流出

– きっかけ

『生産能力チェック』という機能を先行で実装していたが、そのチェックロジックは、先行機能のユースケースに特化して組んだので、後発の別のユースケースからはそのロジックを再利用できず、機能間で振る舞いに差異が発生。

–対応した方法

『生産能力』のドメイン部品を設置してユースケースとは分離し、各ユースケースからそれを呼び出すようにリファクタリング。痛い手戻りだったが、その後はそのドメイン部品を利用しての拡張が行えた。

–反省点

「機能を満たす」という視点だけでなく、機能の奥に眠っている概念を認知し、それを切り出して設計するべきだった。（言うは易く行うは難し。）

ユースケースA 生産能力

ドメイン

ユースケースB

ユースケースA生産能力

ロジック

!

- Before - - After -



4. まとめ



まとめ

DDDは決して銀の弾丸ではなく、むしろ急がば回れの設計スタイル。

– ユースケース軸に加えて、ドメイン軸でも設計を醸成させていく。

コアドメインが安定してくると、システムを成長させやすい。

–逆に言うとドメインが安定するまでは大変。短期決戦では投資を回収できない。

DDDでは知識の配置場所が豊富にあるが、逆にそれだけ配置場所に悩む。

– DDD本の中に方針レベルの記載はあるが、実際には現場での判断も数多く必要。

DDDの哲学をひも解くと、『再利用性』・『DRY』・『凝縮性』といった古くからのソフトウェア哲学そのもの。それらの哲学を引き継いで体系化したもの。

熟練のオブジェクト設計者が常々用いてきた設計プロセスの一部でありながら、グループとしてみると、この業界のほかの人々へうまく伝えられずにいたものだ。これまで我々は、この知識を断片的には提供してきた。しかし、ドメインロジックを構築するための原理をまとめ上げ、体系化したことはなかった。

― Kyle Brown (Eric Evans氏の著書に寄せた賛辞より)



参考文献

エリック・エヴァンスのドメイン駆動設計

– 著者：エリック・エヴァンス

– 出版社：翔泳社

実践ドメイン駆動設計

– 著者：ヴァーン・ヴァーノン

– 出版社：翔泳社

実践UML

– 著者：クレーグ・ラーマン

– 出版社：ピアソン・エデュケーション

Software

ULSアジャイル推進室 基幹系システムの再構築におけるDDD事例 20160312

ULSアジャイル推進室基幹系システムの再構築におけるDDD事例 20160312