ERPの機能分析にドメイン駆動設計が使えないか #dddosaka

オージス総研の「ドメイン駆動設計」の記事に、「戦略的DDDをエンタープライズアーキテクチャに適用した事例」の内容があったのでメモ。

【参考】
[ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場

(引用開始)
DDDの「戦略的デザイン」パターンは企業の経営戦略レベルに適用できるとは言っても、具体例がないとなかなかイメージしにくいと思います。DDDの公式サイトにて、エンタープライズアーキテクチャ（EA）の改善に「戦略的デザイン」パターンを適用した、ノルウェーの大手石油／ガス会社StatOil社の事例が紹介されています。
(引用終了)

Architectural Improvement by use of Strategic Level Domain-Driven Design

(引用開始)
同じくStatOil社の事例として、ERPなどの商用パッケージ製品の評価に「戦略的デザイン」パターンを適用した事例も紹介されています。こちらの事例では、コンテキストマップと責務の階層の組み合わせが、パッケージ製品の評価に不可欠な暗黙知の顕在化に役立ったと報告されています。
(引用終了)

Using Domain-Driven Design to Evaluate Commercial Off-The-Shelf software

【1】いわゆる基幹システムの設計をしていると、長年の保守や機能追加のために、中身のソースも設計もグチャグチャになっている場合が多い。
最悪な場合は、検索しようとしたら3分以上かかってセッションタイムアウトで使えなかったり、画面の機能がそもそも会社の業務をカバーしておらず、結局手作業でカバーしている時もある。

そうすると、業務システムは「膨大なお金を払ったのに投資対効果が赤字」とか「動かないコンピュータとして負債になっている」場合もよくある。
一時期は、日経の記事で盛んに「動かないコンピュータ」の事例が載っていた。

その原因の一つは、基幹系業務システムの設計がまずく、モデルとして抽象化されて開発チームやドメイン専門家が共有しなかったために、度重なる機能追加や障害修正でどんどん設計が劣化していったことだろう。

そんな場面でドメイン駆動設計が生きるのではないか。

【2】たとえば、「ドメイン駆動設計」の第4部「戦略的設計」では、ソフトウェアプロダクトラインに似たような概念「コアドメイン」やコア資産抽出プロセスに似た概念「蒸留」がある。
また、「大規模な構造」では、大規模なシステムの設計戦略が提示されている。

つまり、ドメイン駆動設計のスコープやゴールは、図書館の貸出システムのような簡単なモデルだけでなく、大手石油会社の輸送システムや製造業の生産管理システムなど、大規模な業務システムの設計も意識しているように思える。

PHPメンターズ -> Practical DDD #3: モデルの深さ

以前、「ドメイン駆動設計」を読んだ時は「オブジェクト指向設計の先祖返り」という観点しか持っていなかったが、DDD読書会＠大阪で皆と輪読しているうちに、自分の理解が非常に浅かったことに気づいた。
「ドメイン駆動設計」で言う「モデル」は、UMLでのクラス図のレベルではなく、開発チームやドメイン専門家が共通してつかる言葉「ユビキタス言語」をベースに、かなり抽象化されたモデルを指している。

つまり、デザインパターンのようなプログラミングレベルでもないし、アナリシスパターンのような特定のドメイン(会計、金融、組織人事など)のモデリングパターンだけを指しているのではない。
アナリシスパターンの「知識・操作レベル」のパターンで言えば、「知識レベル」の層に当たる所で、より抽象化されたドメイン(問題領域)で、モデルを捉えようとしている。

だから、「ドメイン駆動設計」のモデルは「ドメインモデル」というよりも「メタモデル」に近い印象を受ける。

【3】基幹システムのような大規模な業務システムの設計が難しいのはいくつか原因があると思う。

一つは、現場の人達が使う業務のドメインと、所要量計算のアルゴリズムや経路探索によるグラフ計算などの数式モデルのようなコンピュータの世界に近いモデルが入り組んでいること。

もう一つは、特定の現場の人達が使う「業務の言葉」が、その業界で一般に使われている「業務の言葉」と意味合いが違っていること。

前者については、「ドメイン駆動設計」の輸送モデルの事例が参考になる。
輸送システムでの経路探索システムは、現場の人が貨物を最短の経路で経路探索の業務を使う時に、その背後では、グラフ計算のようなかなり高度な数式モデルがある。
「ドメイン駆動設計」では、ドメイン専門家が理解するモデルを「コアドメイン」として分離し、グラフ計算のようなモデルは「汎用サブドメイン」として、さらに分離する。
つまり、モデルにおいて、「境界づけられたコンテキスト」でそれぞれのモデルのスコープを決定し、分離することを主眼においている。
そして、コアドメインのモデルと汎用サブドメインのモデルは、「コンテキストマップ」によって、モデル間の関連が明確にされる。

この手法は例えば、製造業の生産管理システムにおいて、ある製品の部品の種類と数量、リードタイムをInputに入れると、どの部品をどのタイミングでどの数量だけ発注したらよいか、を自動計算する所与量計算のモデルにも使えるだろうと思う。
つまり、ドメイン専門家が理解する「コアドメイン」と、その背後にある数値計算のアルゴリズムのモデル「汎用サブドメイン」を分離することで、理解しやすくなるはずだ。

後者については、データベース設計でよく出るホノニム、シノニムの話に似ている。
「ドメイン駆動設計」では請求システムにおける「料金」の話があった。
請求システムのコンテキストとしては、複数のチームが開発に携わっており、顧客に請求する料金とベンダに請求する料金では、必要な金額の項目の意味が微妙に異なっており、その金額計算に必要な項目で混乱した事例があった。
この問題の原因が分かった後、開発チームは、顧客料金クラスと供給者料金クラスを別々に作り、各チームはそれぞれでロジックを定義して、今まで同じように作業し始めた、という。

他にも、僕が最近知った経験では、SIにおける請負契約または委任契約の経費は、とあるERPの製品では「委託費」で呼んでいるが、社内の用語では「外注費」と呼ぶので、社内の人達は「委託費」という言葉を知らなかったことがある。

【4】2014年になった現在では、基幹システムを一からスクラッチで作り直す案件は非常に少ないだろう。
SAPで全ての業務システムを統一するか、各サブシステムを汎用的なERPパッケージ製品で多少カスタマイズして導入してSOAないしEAIで連携するパターンが多いだろうと思う。

すると、現場の業務とERPの機能を比較検討して導入対象を見極めるフィットギャップ分析が重要になってくる。
その作業に、ドメイン駆動設計が使えないか？

つまり、ドメイン駆動設計を大規模な基幹系業務システムの設計に用いて、より高い視点でモデル化して、本来あるべきモデルへ近づけていく手法に使えないだろうか。

この観点でドメイン駆動設計を改めて読み直してみたいと思っている。