Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,476 views

Published on

いまさらアジャイル巡業in広島(アジャイルプロセス協議会、2016/3/12)

Published in: Software
  • Be the first to comment

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

  1. 1. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by いまさらアジャイル巡業 in 広島 事例紹介(基幹系システムの再構築におけるDDD事例) 2016/3/12 ウルシステムズ株式会社 http://www.ulsystems.co.jp mailto:info@ulsystems.co.jp Tel: 03-6220-1420 Fax: 03-6220-1402
  2. 2. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 1 内容 (基幹系システムの再構築におけるDDD事例) 1. プロジェクト紹介 2. Domain-Driven Design 概要 3. 現場から見えてきたもの 4. まとめ By 発表者: 田上 悠樹(ウルシステムズ株式会社) 主にエンタープライズ領域畑で設計・開発をやってきました。 現在 DDDと格闘する悶悶とした日々を過ごす。
  3. 3. ULS 2Powered by Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential 1. プロジェクト紹介
  4. 4. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 3 プロジェクト紹介 クライアント – 製造業(自動車メーカー) 業務領域 – SCM 販売領域 (需要予測、オーダー管理、生産連携) ゴール – 世界140ヶ国からのオーダーを本社で一元管理。 – OEM製品も含めたオーダーの一元管理。 経緯・特徴 – Host系やVB系のサイロ型レガシーシステムをJava系システムに集約。 – 基幹系でかつ長寿命のシステム。 – DDDを採用しての構築。 技術要素 – 開発言語: Java (利用ライブラリ: Spring, JPA, JSF)
  5. 5. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 4 プロジェクトのコンテキストマップ 顧客ドメイン オーダードメイン 製品 ドメイン 生産拠点 ドメイン コンテキストマップ – オーダードメインをコアとし、周辺に顧客、製品、生産拠点のドメインが取り巻く。
  6. 6. ULS 5Powered by Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential 2. Domain-Driven Design 概要
  7. 7. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 6 DDD(Domain-Driven Design ドメイン駆動設計)の概要 DDDとは – Eric Evans 氏が提唱しているソフトウェア設計手法。 – 機能中心ではなく、『ドメイン(ビジネス上の関心領域)』に設計の 重心を置いたオブジェクト指向設計手法の1つ。 DDDが目指している世界観 – 根源的なモチベーションは、副題にある「ソフトウェアの複雑性に立ち向かう」こと。 それに向かって様々な設計哲学が登場するが、本日焦点をあてたいポイントは コレ。 『ドメインの隔離』 ユビキタス言語 ドメインエキスパート モデル駆動設計 リファクタリング 蒸留
  8. 8. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 7 DDDの登場人物 - UI層 - - アプリケーション層 - ドメインの知識を調整し ユースケースを実現 - ドメイン層 - DDDの中心エリア。ビジネスの知識を 集約した小中規模の部品群 - インフラストラクチャー層 - ア プ リ ケ | シ ョ ン エ リ ア 基 盤 エ リ ア Application Service ドメイン部品を組み合わ せて、ユーザーに対して 価値のある機能を提供 Domain Service ビジネス上のポリシー・判断を提供 Value Object コード 数値 にビジネス上の意味を与える Entity 単なるTable模写以上のデータ構造体を提供 Repository (impl) 永続化装置とのやりとりを担当 これらの登場人物同士を 協調させるための FactoryやAggregate といった合わせ技も登場。 ユースケースのエリア ビジネスロジックのエリア
  9. 9. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 8 DDDと他のデザインパターンとの比較 DDDの立ち位置 DDDは特定の業務や設計問題に対して局所的に適用するパターンというよりかは、 アプリケーション全体に適用する知識配置のパターン。知識配置に対する言及が MVCほどマクロでなく、GoFほどミクロではなく、その中間に位置する。 但し、上記パターンと対立しているわけではなく、むしろ共存している。DDD本の中 にもGoFやAnalysis pattern が登場する。 パターン 説明 GoF design pattern 23の設計パターン(Factory Method, Singleton, Strategy, Visitor etc )をカタログ化したもの。アプリケーション全体に対して適用するという より、設計上の問題が発生している箇所に対して目的別に適用する。 GRASP 責任駆動による設計パターン。疎結合性と高凝縮性を軸に、クラスの責 務配置の基本原則をまとめている。情報エキスパート、コントローラー、人 工品などのパターンが登場する。DDDの配置と通ずるところがある。 Analysis pattern エンタープライズ領域に登場する代表的な業務・組織についての概念パ ターンをまとめたもの。在庫、会計、取引、金融商品などの具体的な業務 を題材に、共通の構造を見出してパターン化している。
  10. 10. ULS 9Powered by Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential 3. 現場から見えてきたもの DDDの旨味(総論・各論) DDDの苦味
  11. 11. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 10 DDDの旨味(総論: 部品の共有) 部品の共有 – アプリケーション層とドメイン層の間やドメイン間では、オブジェクト同士が1対1では なく有機的に結びつくので、コミュニケーション図相当のダイアグラムで可視化。 – 他の人が作ったドメイン部品を自分が担当しているユースケースにも組み込めるの で、ロジック実装の部分をショートカットできる。 オーダー 受付 生産拠点 ドメイン 製品カタログ 表示 カレンダー ドメイン 製品 ドメイン 顧客 ドメイン - アプリケーション層 - - ドメイン層 - オーダー ドメイン 生産振分け先の決定 オーダーステータスの更新 オーダー可能期間の確認 OEM製品判定 注文チャネルの確認
  12. 12. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 11 DDDの旨味(総論: システムの成長) コアドメインをベースにしたシステムの成長 – ドメインが安定してくると、そのドメインを再利用してユースケースの追加・変更が行 いやすく拡張しやすい。 – 但し、ドメインを安定させるまでは一苦労で、設計と実装の Try&Error の繰り返し。 恩恵をあずかれるのは、後半戦から。 ドメインを形作るまで投資が必要。 イテレーティブな日々。 ユースケースを追加しやすく投資を回収できる。 インクリメンタルな日々。 安定期 成長期黎明期 コアド メイン コアド メイン
  13. 13. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 12 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コードの例)
  14. 14. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 13 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に復元
  15. 15. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 14 DDDの旨味(各論: 知識の集約 Service)  Service – コアドメインである『オーダードメイン』のサービスは、オーダーに関連する複数のドメ インの知識を集結させて、初めて 『オーダー受付』 というユースケースが成り立つ。 – ユースケースはシステムの成長過程で増えていくので、新しいビジネスイベントが生 まれてもドメイン部品を組み合わせるだけでスケールできるように構造化した。 イベント検出 新規オーダー イベント 製品変更 イベント 納期変更 イベント 将来的に発生し 得るイベント 顧客ドメイン: ○○判定 ○ × ○ … 製品ドメイン: △△判定 ○ ○ × … 生産拠点ドメイン: □□判定 ○ ○ ○ … カレンダードメイン: ○○判定 ○ × ○ … オーダードメイン領域 様々な文脈のオーダー情報 イベント振分け インクリメンタル に実装
  16. 16. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 15 DDDでの性能問題 ドメイン層は中粒・小粒の部品で構成されているため、ときに性能問題が起きやすい。 – 相反する課題 – 対応した方法 再利用を重視して中粒のクエリを採用した。ただし、クエリキャッシュの機能をインフラ ストラクチャ層に実装して、I/O回数を減らす施策を実施した。 DDDの苦味 (性能問題) 性能・最適化 VS 再利用性 課題A ある機能に特化したクエリを書くと、性能メリットはあるが再利用しにくい。 課題B 汎用的な中粒のクエリを書くと、再利用性はあるがトータルでI/O回数が増加。 (いわゆる『マシンガンSQL』というアンチパターンになる。)
  17. 17. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 16 DDDの苦味(知識の流出) 知識の流出 – きっかけ 『生産能力チェック』という機能を先行で実装していたが、そのチェックロジックは、先 行機能のユースケースに特化して組んだので、後発の別のユースケースからはその ロジックを再利用できず、機能間で振る舞いに差異が発生。 – 対応した方法 『生産能力』のドメイン部品を設置してユースケースとは分離し、各ユースケースから それを呼び出すようにリファクタリング。痛い手戻りだったが、その後はそのドメイン部 品を利用しての拡張が行えた。 – 反省点 「機能を満たす」という視点だけでなく、機能の奥に眠っている概念を認知し、それを切 り出して設計するべきだった。(言うは易く行うは難し。) ユースケース A 生産能力 ドメイン ユースケース B ユースケースA 生産能力 ロジック ! - Before - - After -
  18. 18. ULS 17Powered by Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential 4. まとめ
  19. 19. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 18 まとめ DDDは決して銀の弾丸ではなく、むしろ急がば回れの設計スタイル。 – ユースケース軸に加えて、ドメイン軸でも設計を醸成させていく。 コアドメインが安定してくると、システムを成長させやすい。 – 逆に言うとドメインが安定するまでは大変。短期決戦では投資を回収できない。 DDDでは知識の配置場所が豊富にあるが、逆にそれだけ配置場所に悩む。 – DDD本の中に方針レベルの記載はあるが、実際には現場での判断も数多く必要。 DDDの哲学をひも解くと、『再利用性』・『DRY』・『凝縮性』 といった古くからの ソフトウェア哲学そのもの。それらの哲学を引き継いで体系化したもの。 熟練のオブジェクト設計者が常々用いてきた設計プロセスの一部でありながら、 グループとしてみると、この業界のほかの人々へうまく伝えられずにいたもの だ。これまで我々は、この知識を断片的には提供してきた。しかし、ドメインロ ジックを構築するための原理をまとめ上げ、体系化したことはなかった。 ― Kyle Brown (Eric Evans氏の著書に寄せた賛辞より)
  20. 20. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 19 参考文献  エリック・エヴァンスのドメイン駆動設計 – 著者: エリック・エヴァンス – 出版社: 翔泳社  実践ドメイン駆動設計 – 著者: ヴァーン・ヴァーノン – 出版社: 翔泳社  実践UML – 著者: クレーグ・ラーマン – 出版社: ピアソン・エデュケーション

×