6. ドメインとITシステム構築
本ドキュメントの利用は、https://github.com/kae-made/kae-made/blob/main/contents-license.md に記載のライセンスに従ってご利用ください。
Date：2024/4/3 - Version：1.2.0
はじめに
「概念情報モデルをITシステムに組み込む」では“概念情報モデルの概念情報モデル”を紹介し、簡単に主題領域（ドメイン）に言及しました。この節では、“主題領域（ドメイン）”についてより深く説明していきます。
なお、本節ではシンプルに“ドメイン”という用語を使います。
ドメイン
ドメインとは、「なぜシステム化したいのか」という背景を同じくする、システム化したいビジネス対象に含まれる主題や観点などの集まりです。ネット上でシステム開発の文脈で“ドメイン”という用語を検索すると、本稿での意味付けとは異なるものしか出てこないので、それらは全て無視して忘れてください。
ドメインとは
概念モデリングでは、モデル化対象となる現実世界のことをドメインと呼びます。モデル化は、解決したい問題や、理解を深めたいテーマ等の観点のもとに行います。それらを構成する主題の集まりでもあるので、ドメインは、モデリングに対する主題領域の世界とも言えます。
モデリング開始時点でのドメインの定義は、モデル作成チームメンバーの意識合わせのための簡潔な三行程度のシンプルな説明文や、いくつかのビジネスシーンを描いたスケッチなどがあれば十分です。何しろ、その詳細が分からないからモデルを作成していくのですから、曖昧な記述しかしようがありませんから。
ドメインは、概念クラスとそれを特徴づける特徴値の組、特徴値の値を規定するデータ型、概念クラス間の意味的な関係（Relationship）、概念クラスに紐づいた状態モデル（事象、状態、遷移、アクション記述）、つまり、概念モデルの記述によって、その在り様の詳細が規定されます。言い方を変えれば、
ドメインの厳密な定義 ＝ 概念モデル
です。モデル化の対象である、解決したい問題や、理解を深めたいテーマ等は、ビジネス要件だけでなく、意味的に深く関連してまとまった主題群で構成されるものであれば、何でも（概念モデリングそのものさえ）ドメインとして扱って構いません。
モデリングに必須なドメイン ～ ”意味の場” あるいは ”領野”
ある目的のもと何らかの意図をもって対象を抽出する、それが、モデリングという作業です。これは概念モデリングに限らず、あらゆるモデリング技法の基本です。モデリングにおいて抽出されるのは、実際の世界にある何かを、モデリングの目的や意図によってモデル作成者が認識、あるいは解釈した存在です。目的や意図が異なれば、抽出された存在の性質は異なります。概念モデリングでいえば、抽出された概念クラスとその特徴値の組、Relationship、そして、状態モデルが異なります。
自転車に乗ってサイクリングに出かけることを考えてみましょう。サイクリングに出かけるという観点からすれば、主題になるのは、目的地や経路、走行中のスピードや疲労具合による休憩の取り方、遠出の場合宿泊地です。しかし、これらの主題群は、自転車だけからは出てこないでしょう。自転車はサイクリングを行うための物質的条件という必要条件ではありますが、サイクリングの十分条件ではありえません。自転車だけの観点で考えられるのは、ハンドルやサドル、タイヤ、チェーン、変速機の有り無し、それぞれのパーツの製造会社、自転車全体、あるいは各部品の価格、走行距離に応じたメインテナンス、防犯登録、などといった主題が抽出されるでしょう。加えて、ユーザーの視点、自転車の販売業者、製造会社の視点によって、抽出された主題の性質が異なる（＝特徴値や状態モデル）のは容易に想像がつくでしょう。
この様に、モデル作成時に抽出される対象は、それぞれの目的や意図という視点の違いによって、変わってきます。新実存主義という哲学の一分野では、過去数千年に渡って議論されてきた成果の元、
「存在すること」＝ 何らかの意味の場のなかに現れること
とされています。更に、
「限りなく数多くの意味の場が必然的に存在する」
とされています。”意味の場”、これは邦訳では、”領域”、”意味の領域”、”対象領域”、”領野”…と様々な用語が使われていますが、概念モデリングにおける”ドメイン”は、新実存主義の”意味の場”であるとするのが、一番妥当な定義であるというのが、筆者の現時点での理解です。
新実存主義の”領域”は、一般的に用いられている”Domain”とは若干異なることには留意が必要でしょう。あえて”領野（Field）”という言葉を使ってDomain と明確に区別した論考を行っているからです。一般的に存在論で使われてきた Domain という用語は、人間が意図的に構築したものという意味合いがあるようです。概念モデリングにおける Domain は、一般的な存在論の Domain ではなく、新実存主義の Field であることに注意してください。
～ 以下、”マルクス・ガブリエルの哲学” P27 より抜粋 ～
私の領野概念（Field）の使用法は、存在論における領域概念（Domain）にとって代わることを意図している。領野は一般的に構築されるものではなく、その効力は対象が入り込むことで感じ取られる。〔中略〕領野は客観的構造を提供し、その構造内で現出する対象と相互行為をなす。領野は既に存在し、対象はその領野を通じて自身の性質を転換する。領野は水平でも地平でもない。事物の在り方を知る手立てを説明するために導入された、認識論的存在者ないし客観ではない。領野がなければ何も存在しないというなかでの、事物の在り方の本質的な部分のことである（2015 157-158)
～ 以上、抜粋終わり ～
以上を踏まえ、”Art of Conceptual Modeling”におけるドメインという用語をフィールドと書き換えるべきか、とても悩んでいますが、現時点では保留としておくことにしました。
概念モデリングにおける”ドメイン（意味の場・領野）”は、単なるモデリング上のテクニックではなく、対象を記述する時の本来的な必須要件です。
加えて、複数の”ドメイン（意味の場・領野）”が存在することも本来的です。加えて、”ドメイン”は並列であり、階層化はしないことも、”ドメイン（意味の場・領野）”の本質から自明です。
IT システムを構築する際にも、以降で説明するドメイン（意味の場・領野）群が必須であると心得てください。
ドメインの種別
ドメイン毎に考える
概念モデリングの過程において、別のドメインのクラスとして定義したほうが良い概念が候補として抽出されることが良くあります。クラスの抽出に当たっては、モデル化対象のドメインに属するクラスか否かを常に吟味します。適切なクラスかどうかは、対象ドメインの他のクラスとの関係を考察することで判断します。
同じドメインに属するクラスの間では、そのドメインの主題や観点において適切な関係が定義できます。異なるドメインに属するクラスの間ではそのような関係を定義することはできません。モデル作成の過程でそんなクラス候補が出てきたら、そのクラス候補が意味するところや背景などを検討し、必要であれば別のドメインのクラスとして切り出していく、そんな風に進めていくのが良いでしょう。
※ 本稿で“ドメイン”と呼んでいるものを簡潔に説明するのは大変難しいのですが、例えば、複数人で何らかのテーマで議論をしている最中に、同じような言葉を双方が使っているのにも関わらず議論が全くかみ合わないことがあります。これは議論の当事者それぞれが頭に描いている主題がそれぞれ違っている、あるいは、観点が異なっていることに起因します。概念モデリング的には、それぞれの議論の当事者が思い描いていることがそれぞれ独立した“ドメイン”を頭に描いて、議論をしていると考えます。他社とより良い議論をするために、議題のドメインを明確化しましょう。
現在確認中ですが、本稿の”ドメイン”は、ベースとなっている Shlaer-Mellor 法の提唱者の一人、Sally Shlaer さんが数学者であること、方法論の提唱時期から考えて、”領域理論 - Wikipedia” がベースになっているのではないかというのが、著者の現時点での考えです。
ドメインはその特性上、以下の４種類に分類できます。
アプリケーションドメイン
サービスドメイン
インフラストラクチャドメイン
アーキテクチャドメイン
これらの分類は、適切なドメイン定義の指針にもなりえます。
アプリケーションドメイン
IT化したいビジネス要件の主題を扱うドメインです。ネット上でよく見かける定義はこの分類に近いです。「概念情報モデル」の章で例として挙げた、“商品販売”や、“装置管理”等がこの分類にあたります。“人事”や“経理”も含め、ビジネスに関するものでIT化したい対象には必ず１つ以上のドメインが存在します。
サービスドメイン
この分類に属するドメインは、アプリケーションドメインを、IT技術を使って実現するための、“仕組み”に関する概念群で構成されます。
例として“装置管理”を使って説明します。
これまで述べてきたように、概念情報モデルが定義する制約に従って存在する、インスタンス、インスタンスの特徴値の値、他のインスタンスとのリンクは、常に今どうなっているかを示しています。そのため、このモデルでは、“今どうなっているか”という問いにしか答えられません。ある装置インスタンスに着目して、
その装置インスタンスの温度の値が過去のある時点でどういう値だったか
過去のある期間どんな変化をしていたのか？
という問いかけは、記録された現実のデータをもとに最適な制御を模索する上では必須のものです。概念情報モデルの道具立てを使って、素直にモデル化するとすれば、
というクラスと、装置との間の関係を定義するのが自然に思いつく方法でしょう。
しかし、過去の変化という事では、“消費電力”という特徴値についても当然同じ問いが可能であり、さらに言えば、その装置インスタンスの設置場所の履歴、さらには、インスタンスが作成された（現実世界では装置が設置されてシステムの管理下に置かれた）時点や、リンクの切り貼りの履歴も見たいはずです。この様な様々な履歴に関する情報についてクラスと関係を定義していくと、概念情報モデルはあっという間に蜘蛛の巣の様な不様で汚い図になり果てます。
※ 不様な様は、テキスト形式で描いているときには気が付きにくいものですが、モデルを図で書いたときに際立ちます。
この様な無様な状態が、正に、別ドメインの概念が混入してしまっている状態であり、モデル作成者の頭の中が図と同様混乱しきっていることの証明です。この様な状況に対しては、“値の経過を管理して可視化したい”というドメインがあると考えて、そのドメインに属する概念群を抜きだし、別の独立したドメインを定義します。名前は、便宜上、“テレメトリ”とします。このドメインの概念情報モデルを以下の様にモデル化すると、
“装置管理”ドメインの“装置”インスタンスの“温度”の履歴は、このドメインの“Time Series Instance”と“Time Series Data”のインスタンスとして保存することになります。“消費電力”についても同様です。
図の“Time Series Data”クラスの“Value”という名前の特徴値は、アプリケーションドメイン側での時系列データとして保持したい、様々な特徴値と対応付けられます。対応付ける特徴値は数値の場合もあり、テキストや列挙値の場合もあり、様々なデータ型の値を保持する必要があるので、この特徴値のデータ型は、なんでも格納できるデータ型という意味を込めて、“ANY”型としています。
この、“テレメトリ”の様なドメインが、サービスドメインという分類に属するドメインです。対応付けられる側の概念情報モデルは、あくまでも、モデル化対象のドメインが、どんな概念で構成され、その概念はどんな値のセットで特徴付けられるかという表明にすぎません。その値の変化を記録するのは、過去の履歴を見るための仕組みであって、元々のモデル化対象になっていたドメインとは異なる主題である、と考えるわけです。
この様な考え方で、“テレメトリ”というドメインを定義しておけば、“装置管理”のクラスだけでなく、“商品販売”をはじめとする、様々なドメインの概念情報モデルを汚すことなく、インスタンスや関係、特徴値の過去履歴を保持・参照が可能な仕組みを適用できます。
サービスドメインは、“テレメトリ”のほかにも、様々な主題領域（つまりドメイン）に対して、同様な考え方を適用して、抽出できます。
例えば、ITシステムのビューを作成するためのGUIや、３Dモデル、AI学習や学習済みモデルの配置方法、セキュリティ、認証基盤、データベースなどもサービスドメインとして定義可能です。
自己言及的な説明になってしまいますが、作成するアプリケーションドメインの概念情報モデルの良し悪しは、いかにサービスドメインをうまく抽出できるかにかかっています。
また、全てのサービスドメインは、特定のアプリケーションドメインとは意味的に切り離されているので、様々なアプリケーションドメインに対して利用可能です。ソフトウェア開発における汎用ライブラリのような特徴を持っているので、抽出したサービスドメインは全てカタログ化し、チーム内で資産として共有し、再利用します。
読者の参考になるよう、セキュリティやGUI、3Dモデルなど、よく使われるサービスドメインのサンプルをまとめた、「ドメインカタログ」を公開しているので、ご参照ください。
アプリケーションドメインは「ビジネスで何がしたいか」を主題した概念モデリングであり、そのビジネスに詳しい専門家が行う領域なのに対し、サービスドメインは、セキュリティならセキュリティの専門家、GUIならユーザーインタフェースの専門家、AIならAIの専門家と、それぞれの分野の最新動向や、利用可能な技術やサービスを熟知した専門家が担当する領域です。それぞれのドメインは独立していて概念的には無関係なので、ドメイン毎にそれぞれの専門家が並行して概念モデリングを進めることができます。
インフラストラクチャドメイン
アプリケーションドメインとサービスドメインを使って実際のITシステムを構築する際に使用する利用可能なサービスやライブラリ、フレームワークを扱うドメインがインフラストラクチャドメインに分類されます。ロジックを実装するプログラミング言語も該当します。
例えば、前に紹介した概念情報モデルをそのまま実装できる Azure Digital Twins や、現実世界に設置された機器とITシステムの接続・相互通信の機能を提供する Azure IoT Hub、テレメトリデータを蓄積し高速なクエリーを可能にする Time Series Insights、リレーショナルデータベース等、ソフトウェアの実装で必要な道具や部品は全てインフラストラクチャドメインとしてモデル化の対象となりえます。Microsoftが提供しているサービスのみ例として挙げましたが、Amazon Web Service や Google、オープンソースプロジェクトが提供する近しいサービスやフレームワークも含まれます。これらすべてを便宜上、“実装部品”と呼ぶことにします。
上に挙げた各種サービスは、ほとんどの場合、サービスプロバイダーから公開された説明ドキュメントがあり、サービスを利用するための REST API やライブラリの API が記述付きで公開されています。これらのドキュメントをよくよく熟読してみると、用語の定義や機能の説明はあっても、用語が意味する概念間の関係、特に多重度は曖昧な場合が多々あります。原文が英語なら原文を読み下したほうが良いのですが、不定冠詞や定冠詞、単数や複数を厳密に使い分ける英語ですら、細かい部分の説明が曖昧な場合が多いので、日本語での説明の場合はなおさらです。
インフラストラクチャドメインに対する概念モデリングは、二つの目的で行います。
その実装部品を深く理解する
アプリケーションドメイン、サービスドメインの実装戦略を考えるための基盤を作る
例えば、Azure IoT Hubを例にすると、このサービスは非常に沢山の機能や設定を持っていて、かつ、操作対象としての概念もたくさんあるので、“概念情報モデル”を使って自然言語で説明されている内容を明確化すると理解が深まるとともに、ドキュメントには明確に記述されていない部分も発見できます。モデル化により理解が深まるだけでなく、サービスプロバイダーへのはっきりした質問が可能になったり、複数のサービスプロバイダーから提供されている一見似たようなサービスの違いを見つけることもできます。
参考までに Azure IoT Hub に対して、筆者が作成した概念情報モデルの一部を図で紹介しておきます。
インフラストラクチャドメインに対する概念モデリングの、二番目の目的である“実装戦略を考える”は、ITシステムの一般的な開発工程における“設計”に相当します。
アプリケーションドメインやサービスドメインのそれぞれの概念情報モデルは、インフラストラクチャドメインが対象とする実装部品を使って、構築したいITシステムの一部として実際に動くソフトウェアとして、“変換”され“実装”されます。
アプリケーション、サービスドメインのそれぞれの概念情報モデルで定義された、クラス、クラスのプロパティ、関係、及び、概念情報モデルに対する操作、のそれぞれが、インフラストラクチャドメインの概念情報モデルの要素にどのように対応付けるかを、ビジネス要件から求められるITシステムへの非機能要件を元に決定しルール化する過程を、本稿では、“設計”と呼びます。一般的なソフトウェア開発における設計においても、“与えられた機能要件と非機能要件を、ソフトウェアを利用可能な実装技術を使って実現する方法を決定すること”なので、本質的な相違点はありません。
設計に関するルールが決まれば、それぞれのドメインの概念情報モデルであらかじめ定義しておいたインスタンス群の初期状態から、順にインスタンスを取り出して、ルールを適用してくことにより、実際に動くソフトウェアコードや設定スクリプトが出来上がります。つまり、“モデル”から“ソフトウェア”に“変換”できるわけです。この過程は、人手でもできますし、概念情報モデルのリポジトリと変換ルールをデジタル化して、コンピュータ技術を駆使すれば自動化できます。汗水たらしてコンピュータが扱えるぐらいの厳密さで作成した概念情報モデルのおかげで、旧来のソフトウェア開発プロセスで最も人出が必要な後半の工程が自動化できるわけです。勿論、自動生成では不可能な、人が書かなければならないソフトウェアコードの部分も若干残りますが、旧来型のソフトウェア開発プロセスに比べれば微々たるものになります。
本稿で解説している概念モデリングを活用したITシステム開発方法では、設計と実装の工程は、複数のドメインを統合する作業が該当します。
ドメインの統合では、概念情報モデルの概念情報モデルを使って、あるドメインの要素と別のドメインの要素の対応付けと、コードを実装するためのパターンを定義していきます。
”概念情報モデルの概念情報モデル”は”メタモデル”とも呼ばれます。
ソフトウェア化可能な対象であれば、あらゆる対象に対して概念情報モデルを定義することができるということは、概念情報モデル自体も、モデルを構成する、概念クラス、特徴値、Relationship、データ型というモデル要素を概念情報モデルとして定義可能という事を意味し、モデル化したものを”概念情報モデルの概念情報モデル”と呼びます。
次節で、アプリケーションドメインとサービスドメイン、サービスドメインとインフラストラクチャドメインなど、統合するドメインの特徴に応じた対応付けのパターンを紹介していきます。
ドメインを統合する
この節では、ドメイン毎に作られた概念モデルを統合して、実際に動くITシステムを構築していく方法をより詳細に解説します。
ドメインをインフラストラクチャドメインにマップする
「概念情報モデルをITシステムに組み込む」の章の「グラフデータベース、あるいは、オブジェクト指向データベース」の節で、アプリケーションドメインの概念情報モデルを、Azure Digital Twins で実装する方法を解説しました。
これは、ビジネスを記述するアプリケーションドメインの概念情報モデルと、Azure Digital Twins という実装技術に対するインフラストラクチャドメインを統合することに相当します。統合は、アプリケーションドメインに対し、
概念情報モデルで定義された各種制約＝スキーマの管理
概念インスタンス群の状態保持方法
概念インスタンスへの操作
の3つについて、最も適切と思われる実装技術を選択し、選択した実装技術に対応するインフラストラクチャドメインにどう対応付けるかというルールを決めるというものでした。
この作業は、アプリケーションドメインに限らず、サービスドメインとインフラストラクチャドメインの統合においても、基本的には同じ作業を行うことになります。違うのは、アプリケーションドメインの場合は、概念情報モデルの概念情報モデルを扱うのにふさわしい実装技術を選ぶのに対して、それぞれのサービスドメインに適した実装技術をそれぞれ選択し、そのインフラストラクチャドメインと統合するという点だけです。
より具体的に言えば、それぞれのサービスドメインに対して定義された、概念情報モデルを構成する概念群と近しい概念群を扱う実装技術を選択することになります。
例えば、テレメトリドメインならば Time Series Insight、セキュリティなら Active Directory といった具合です。
勿論、近しい概念群を扱う実装技術であれば、他のベンダーやオープンソースプロジェクトが提供するサービスやフレームワークでも構いません。
実装技術の選択においては、扱う概念群が近しいという条件に加えて、ビジネスを支援するITシステムへの非機能要件を満たす事も、重要な選定基準です。ITシステムを構成するアプリケーションドメイン、サービスドメイン、全てに対して概念情報モデルが作成されている場合は、非機能要件は、概念情報モデルの用語を使って、以下の項目で表せます。
扱えるインスタンスやリンクの最大数
操作のパフォーマンス
インスタンスやリンクの数や操作数に応じた運用コスト
ビジネスを支援するITシステムの構築プロジェクトにおいては、利用ユーザー数や管理対象の機器数、応答性能、運用コストの上限等は、大抵の場合、投資対効果の観点から、概要が決まっているはずです。
それらに基づき、概念情報モデルの制約に従ってインスタンスの状態を設定すれば、ここで挙げた最初の2つの項目の数値を確定でき、利用候補の実装技術の利用料と照らし合わせることにより、最後の項目を算出できます。実装技術を提供するベンダーが公開している利用料金の定義があいまいな場合は、ITシステムのプロトタイプを作成して少数のインスタンスとリンクを設定して実際に動かしてみて利用料を確認するのも有効な見積手段の一つです。
インフラストラクチャドメインへの対応付けを考えるにあたっては、様々なケースで適用可能な実装パターンを知っていると非常に役立ちます。
マイクロソフトが公開する「Azure アーキテクチャセンター」では、様々なパターンを紹介しているので、読み込んでみるのもよいでしょう。
※ 概念モデリングの初学者の素直な感想は、「めんどくさくね？」だと思います（笑）。しかし、ある程度の正確な見積を行うには、パフォーマンスやコストに関わる項目の洗い出しが絶対に必要です。今、別の有効な手段があるならそれを使えばいいですが、ないなら、ここで解説している方法にトライしてみることをお勧めします。
※ IoTやビッグデータを扱うITシステムの構築について、よく、「小さく始めて大きく育てる」と言われますが、これは、「とりあえず出来るところから始めて成功事例を作って横展開してく」という意味ではありません。このやり方では、たとえ成功したところで、変化を望まない保守的な人達からは「たまたまやりやすい部分ができただけの特殊な事例」と言われて横展開はできないでしょう。ビジネスのIT化は、経営トップ層が関与して全社的に進めなければいけない組織レベルの戦略的な取り組みです。本稿で紹介してる概念モデリングによる開発においては、「小さく始めて」は、一部のドメインの試験的な実装で、少数のインスタンスやリンクの状態から初めることを意味し、その結果を元に、概念情報モデルの修正、実装技術の再選定、対応ルールの修正を行い、順次実装するドメインを増やす、あるいは、扱うインスタンスやリンクの数を増やすことが「大きく育てる」に該当します。
アプリケーションドメイン、及び、サービスドメインと、インフラストラクチャドメインの対応付けの概要は以上の通りです。
それぞれのドメインの特徴に応じたより具体的なやりかたについては、「ドメイン実装に関する実践ガイド」を参照してください。
アプリケーションドメインとサービスドメインの対応付け
この対応付けは、アプリケーションドメインで定義された概念情報モデルをITシステムに実装する場合に、時系列データの扱いや更新履歴管理など、特定の主題領域に依存せず再利用可能な汎用的な概念を追加したり、ユーザー認証やアクセス管理、データの保存など、ITシステム化する際に必要な機能の追加に関するルールを定義します。
テレメトリドメインのアプリケーションドメインへの対応付けを考えます。
アプリケーションドメインの概念モデルで定義されたクラスの特徴値の一部を時系列データとして扱うという事なので、“概念情報モデルの概念情報モデル”の“property（特徴値）”クラスと、テレメトリドメインの“Time Series Instance”クラスには、以下の様な関係があると表現できます。
概念情報モデルの操作の観点からすると、
アプリケーションドメインの概念情報モデルの、テレメトリ管理したい特徴値に対して“時系列データセット指示”クラスのインスタンスを作成（同時に関係の多重度の定義に従って“時系列データセット”のインスタンスが一つ出来上がる）する
というルールを定義したことになります。後は、“時系列データセット”のインスタンスを順次取り出し、“テレメトリ”ドメインをインフラストラクチャドメインに対応付けるルールに従って、実装に変換していけば、“テレメトリ”ドメインをアプリケーションドメインに対応付ける作業が完了します。
アプリケーションドメインを Azure Digital Twins で実装している場合は、Azure Digital Twins のTwin Property 更新通知のエンドポイントで更新情報を受信し、“テレメトリ”ドメインの実装にデータを供給するような構成になります。
アプリケーションドメイン側の、特徴値のテレメトリ管理指定は、人が手動で行います。「概念情報モデル」の章で紹介したYAML風のテキストで概念情報モデルを定義している場合は、特徴値の“description”の下位要素で、“@telemetry: true”のようなメタデータ指定を行い、それをプログラムで読み込み、メタデータ指定があった場合は、該当する特徴値の更新のみをウォッチするフィルターを持つ Azure Digital Twins の更新通知エンドポイントを作成するスクリプトを生成するような仕掛けを作っておけば、実装工程の自動化が可能です。
ここで紹介したテクニックは、C# の属性や Java のアノテーションでも使われているテクニックと同じです。
以上、“テレメトリ”ドメインを例に説明してきました。手順をまとめると
概念情報モデルの概念情報モデルのクラスと、サービスドメインの概念情報モデルのクラスの対応を、定義する
アプリケーションドメインの概念情報モデルのインスタンスの対応する要素に印をつける
アプリケーションドメインの概念情報モデルのインスタンスを順次取り出し、印のついた要素に対して、サービスドメインのインフラストラクチャドメインへの変換ルールに従って実装する
となります。
機器からのテレメトリは、また、別の見方による、別の対応付けも可能です。
図13 の”装置”という概念クラスには、”温度”という特徴値が定義されています。”装置管理”というドメインでは、製品の一連の製造過程の幾つかの時点で、この”温度”という特徴値を参照するだけだとすると、”装置管理”というドメインを対象とした概念モデルの記述において、”装置.温度”は単に参照するというアクションがどこかに存在していれば十分で、”装置.温度”の値の更新に関するアクションは記述する必要はないと、考えるのが概念モデリングの流儀です。
「え？でも現実世界の装置の実際の温度の変化に合わせて概念モデル上の”装置.温度”を更新しないといけないよね？」という読者の声が聞こえてきそうですね。「Art of Conceptual Modeling」で解説している概念モデリングにおいては、
”装置.温度”の更新の仕組みは、”装置管理”ドメインを元に作成した概念モデルを、ソフトウェア成果物（プログラムコード）に変換する時に織り込めばよい
と考えます。例えば、現実世界の装置には、その装置の温度を計測する温度センサーが装備された IoT 機器が装備されていて、その機器が一定間隔で温度を計測し、ネットワーク越しにテレメトリデータとしてサービス側に送信している場合、
予め、IoT 機器のアイデンティティと”装置管理”ドメインの”装置”の概念インスタンスのアイデンティティを対応付けておく
ある IoT 機器がテレメトリデータとして計測した温度をサービス側で受信した時
送信元の IoT 機器に対応する”装置”の概念インスタンスを検索し特定する
特定した概念インスタンスの”温度”特性値を、受信した温度の値で更新する処理を起動する
という実装上の仕組みを用意すれば十分です。
他のケースとして、”装置管理”ドメインにおいて、装置の温度が、事前に決められている温度を超えた場合に特別な振舞をするようなシナリオがあるとします。この様な場合は、”装置”という概念クラスに状態モデルを定義し、その状態モデルで、例えば、”許容温度超過”という名前の事象（イベント）を受信し、”温度異常状態”に遷移して何らかのアクションを行うような記述を行うのが一般的です。
この場合も”装置.温度”特徴値の更新の時と同様、”許容温度超過”という事象を”装置”のある特定の概念インスタンスに送信する様なアクションを概念モデルで記述する必要はありません。
例えば、IoT 機器からのテレメトリーデータを、”装置.温度”の更新サービスに流しつつ、並行して Azure Stream Analytics にテレメトリーデータを逐次入力し、
”装置.閾値温度”を参照データとして使いながら、温度の超過を検出して後段に超過したことを示すデータを流す
送信元の IoT 機器に対応する装置”の概念インスタンスを検索し特定する
特定した”装置”の概念インスタンスに”許容温度超過”という事象（イベント）を送信する処理を起動する
といった仕組みで実現可能です。
これは、
ビジネスシナリオを記述するアプリケーションドメイン
現実世界の物理状態の収集・更新を担う、”IoT 機器” というサービスドメイン
インプリメンテーションドメインとして ”Azure IoT Hub” をマッピング
連続的なデータ流への統計処理や機械学習による条件抽出を担う、”データストリーム分析”というサービスドメイン
インプリメンテーションドメインとして、”Azure Stream Analytics” をマッピング
というドメイン群に分割してモデル化し、システムに統合する、一つのパターンです。
以上、取り上げた例は、およそ考えられる様々な実装のパターンのごく一部ですが、他のサービスドメインについても、アプリケーションドメインへの対応付けは、基本的にここで上げたような要領で進めます。
この節のタイトルは、「アプリケーションドメインとサービスドメインの対応付け」としていますが、「アプリケーションドメインの概念情報モデルにサービスドメインを対応付ける」といったほうが、実態をより正確に表現しています。作業を進める際、先にアプリケーションドメインの概念情報モデルがあって、それにサービスドメインを適用して実装に変換するのが基本です。
また、サービスドメインのインフラストラクチャドメイン対応は置き換えが可能です。つまり、同じアプリケーションドメインのモデルに同じサービスドメインを対応付けていても、サービスドメインの実装技術を変えれば、異なる実装技術上で動くソフトウェアモジュールが出来上がります。この特徴は IoT の様に、同じ機能ロジックを、クラウド上だけでなく、現場側に設置されたサーバー上や、専用機器向けのボックスHW上で動かしたいようなケースで威力を発揮します。
概念情報モデルのどの要素と関連付けるか、どういうルールを決めるかは、利用するサービスドメインによって様々です。より実践的なガイドは、こちらをご覧ください。
アプリケーションドメインとアプリケーションドメインの対応付け
製品を製造販売している会社を考えてみます。この会社のビジネスとして、“生産管理”、“商品販売”、“装置管理”といった複数のドメインが定義されているとします。ほかに、“人事”や“経理”などもIT化の対象として、ドメイン定義がなされているものとします。それぞれのドメインは、会社の事業部や部課がそれぞれの業務として担当し、それぞれの流儀で使いやすいITシステムが構築され運用されるのが一般的でしょう。経営トップ層が、今後のビジネス戦略を決定するための、「今会社のビジネスはどうなっているか」を把握する仕組みを構築する場合、業務毎に運用されているITシステム間の連携が必要になります。
仮に、全社的な統制がなく、現場のボトムアップ主導により、それぞれの業務用ITシステムが、それぞれの流儀で開発されていて、データの扱い方や実装方法がバラバラでサイロ化してしまっている場合、統合は現実的には不可能でしょう。逆に、経営層がトップダウン主導でシステム化を決定し、各事業部の業務をよく理解していない開発チームが、全社横断的にそれぞれの業務向けのITシステム構築を担当した場合は、現場の担当者が、かゆいところに手が届かないITシステムを、苦痛をこらえながら使い続けることになるかもしれません。
概念情報モデルを使ったITシステム開発は、このような事態を解決する手段を提供します。各事業部それぞれの主題を扱うドメイン毎に、概念情報モデルが同じ形式で定義（もちろん業務に詳しい現場の担当者の概念モデリング作業への参加は必須です）され、共通のサービスドメインの利用と設計パターンに基づいたITシステム構築がなされるからです。
例えば、“装置管理”と“商品販売”を紐づけてみたい場合は、それぞれのドメインの概念情報モデルを使って、対応するクラスを見つける手助けができます。
工場の稼働状況の最適化と商品販売の在庫管理を結び付けたい場合も、同様に手がかりとして概念情報モデルを利用できます。
更には、装置管理で装置のインシデントの担当者を、人事管理を目的として横串で見たいときには、人事ドメイン上の社員クラスとの紐づけで行えます。
この様な、アプリケーションドメイン間の対応付けは、“概念情報モデルの概念情報モデル”を使うと、図の様に定式化できます。
異なるドメインに属するインスタンス間の対応付け情報は、“概念情報モデルの概念情報モデル”に記載した Instance クラスを使って、図の様に Mapping クラスのインスタンスとして表現可能です。Mapping クラスのインスタンスの表を思い浮かべれば、データベースで保持するような仕組みを用意してITシステムに組み込めることが理解できるでしょう。
この作業は、それぞれの開発対象の主題領域を定義して、概念情報モデルを作っておけば、後付けできるのがポイントです。つまり、概念情報モデルを使ってそれぞれの業務用ITシステムが構築されていれば、ビジネス上必要になった任意の時点で、ITシステムへの機能追加ができるので、ITシステムのアジリティを高めます。
※ 「でも概念情報モデルとかいうめんどくさいもの造らなきゃいけないんでしょ？」という読者の声が聞こえてきそう（苦笑）ですが、そもそもの話として、特定の業務に特化して使いやすいITシステムを開発すれば、特化した概念構造、特化した操作感になるのは論理的な帰結です。更に、特に開発プロセスを規定せずに各開発チームの流儀でばらばらにシステムを構築すればサイロ化するのは当然でしょう。サイロ化を防ぐ唯一の方法は、「全開発チームが共通のルールに従ってデータ構造や操作感を定義し実装する事」です。読者の組織が既にそのような手段を持っているならそれを使えばよいだけの話です。なければ、本稿で解説する概念モデリングと実装方法の利用をお勧めします。
以上、ドメイン群を統合することにより、IT システムを組み立てる方法を解説してきました。本稿で何回も言及しているように、主にモデルの規模により便宜的に分割したアプリケーションドメインは例外として、基本的にドメインは意味論において独立した存在（数学的に言えば直交関係ともいえる）であり、直接的で論理的な依存関係はありません。IT システム構築の段階で、ソフトウェアへの変換において対応付けが行われ、実装という意味論においてはじめて論理的な関係が生じます。
サイクリングというドメインは自転車なしでも記述できますが、実際にサイクリングを行うには自転車が必要なのと、同じです。
ドメイン・チャート
IT システム構築において、ドメイン間の実装上の論理関係を図示化したい場合は、下図の様に、楕円で表したドメインと、ドメイン間の論理関係を矢印で示した図を使うと便利です。
この様な図を”ドメイン・チャート”と呼びます。
ドメインとドメインをつなぐ矢印は、Shlaer-Mellor 法の時代から、”Bridge” と呼ばれてきました。”Art of Conceptual Modeling” においても、”Bridge”（日本語表記ではブリッジとする）と呼ぶことにします。
一見すると Bridge は、ドメイン間の階層を記述しているように見えますが、それは誤解です。Bridge もまた、二つのドメインを選択したときに生じる、意味の場・領野です。つまり、ドメインの一種ということになります。
工程の自動化
最新のIT技術を活用した、概念モデリングを電子化と概念情報モデルのデジタル化により、インスタンスやリンクの設定、ドメイン間の対応付けの作業支援アプリケーション構築が可能になり、対応付けのルールも含めてデジタル化すれば、従来のソフトウェア開発における実装工程を大幅に自動化できます。また、デジタル化された資産、作業工程は、今流行りの DevOps とも相性が良く、DevOps環境にも容易に組み込めます。
ソフトウェアエンジニアリングに対する深い理解と実装技術に関する幅広い知識と豊富な経験を持っているソフトウェア技術者にとって、概念モデリングから実装までを自動化する開発環境の構築活動はとても魅力的な作業であり、腕に覚えがあればあるほど、100％の自動化環境を作りたくなる誘惑にかられるものです。しかし、自動化を進める場合には、
構築した環境を使うのは、一般的なレベルの技術者を含む複数の他人である
中途半端な自動化はかえって手間を増やすだけである
への留意が必要です。自動化が威力を発揮するための前提は、
開発に参加する全ての技術者が、概念モデリングの有効性を理解している
自動化環境構築にかかるコストが、自動化対象工程自動化による削減可能なコストに見合う
ことが最低条件です。
自動化を進めるにあたり、並行して、概念モデリングと自動化環境のトレーニングを用意し、適宜開発チームに提供していきましょう。
本稿で説明した概念情報モデルを使ったソフトウェアの実装は、概念情報モデルのインスタンス状態にルール化されたパターンを適用して実装ロジックを作っていくので、実装工程にかかる工数は、
実装工数 ∝ Σ（インスタンスの規模 × パターン数）
であり、この工数は自動化によって省力化されます。
※ 従来型の開発のケースで、設計や実装方針が各担当者に任されている場合、概念モデリングによるシステム開発における、対応付けルールとパターン定義をそれぞれの担当者が実施していることになります。サービスドメインやインフラストラクチャドメインに相当する概念に対応するための基本方針的なものは、流石に従来型の開発でもあるでしょから、概念モデリングの開発工程の規模を Σ（ドメイン一個当たりの工数）とすると、従来型では、≒ 07 × 担当者数 × Σ（ドメイン一個当たりの工数）ぐらいではないかと思われます。
概念モデリングを活用したシステム開発の自動化は、見方を変えれば、システム開発工程を電子化し、デジタル空間上に写しを作る、システム開発工程のデジタルツイン化であり、それを活用したシステム開発工程のデジタルトランスフォーメーションであるという見方もできます。
ビジネス向けのITシステムと同様、小さく始めて多く育てる進め方も有効でしょう。
変換による自動生成の技術体系を、より詳しく理解したい方は、
「Art of Auto Sofutware Development Deliverables Generation」を、概念モデルからの”変換による自動生成”が、実際どういうものか、興味のある方は、以下をご参照ください。
「BridgePoint で作成した概念モデルを In Memory で動作する C# アプリケーションライブラリに変換する」
アーキテクチャ再考
“アーキテクチャ”という用語は、普段のソフトウェア開発においても、よく使われる用語です。大抵の場合、開発対象のシステムの機能構成図やデータの流れを概観する図と補足情報をアーキテクチャと呼んでいる事が多いです。
実は、アーキテクチャは、ISO/IEC/IEEE 42010 で明確に国際標準として定義された用語です。
この標準において、Architectureとは、
⟨system⟩ fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
であり、
An architecture is what is fundamental to a system — not necessarily everything about a system, but the essentials.
と定義されていて、システムを構成の全てではないが、その本質を記述するモノだとしています。
更に、“fundamental”とは、
That which is fundamental to a system may take several forms:
- its elements: the constituents that make up the system;
- the relationships: both internal and external to the system; and
- the principles of its design and evolution.
であると定義されています。本稿で解説してきた概念モデリングと実装方法は、主題領域ごとに elements=概念クラス と relationships=関係 を抽出して定義し、principles of its design and evolution=それらを実装技術に対応付けるルール を定義するという対応が成り立つので、本稿で紹介した作業工程は、アーキテクチャを厳密に定義する過程であると、言ってよいでしょう。
まとめ
以上、概念情報モデルの基盤となるドメインの深堀と、複数のドメインの対応付けによるITシステムの設計・実装、及び、その自動化について解説してきました。
これまで説明してきた内容を踏まえ、最後に、まだ解説していない、「概念振舞モデル」を読んで、概念モデルを使ったITシステム開発に必要な最後のピースを埋めてください。
本コンテンツでの解説は、あくまでも概念モデルを使ったシステム開発を行うための基礎知識に関する内容です。より実践的なテクニックを学びたい方は、「概念モデリング・システム構築実践ガイド」に進んでください。
この記事が気に入ったらサポートをしてみませんか？