（※最初にDDDに関する論の主戦軸を整理してみた（2020年版）をお読みください。こちらは同記事に対する追加となります。）
一旦振り返り（設計者は"神"な訳ではなく、せいぜい事業者の代理人だった）
ただ、DDD本の「象のモデル」の話は、ちょっとミスリードを誘うと思っている。というのは、「象」は、各アクターが観察する以前に客観的（※「客観とは？」には立ち入らないが。。）に存在している。このことから、「象」という全体像は"自然"に存在する、全体像は各アクターの個別の要求を統合する過程で自ずと浮かび上がる、各アクターの個別のメンタルモデルは表層的なものであり、真に理解を深めることで"イデア的正解"たる全体像に到達できるという分析過程、を想起してしまう。
「象のモデル」による例は、「厨房とホールの連携」のようなケースでも、連携した姿は頑張れば分析的に見出せるはず、ということを言っているように受け取れてしまう。でも実際のシステム設計の場面では、統合モデルに"正解"はない。統合モデルは分析的には見出せない。分析的に見出せるのは、「ホールの業務」と「厨房の業務」だけである。そこではたしかに各当事者（アクター）が現にやっているアクティビティを分析できる。しかし両者の統合は、統合モデルは、誰かが作り出さなければならない。
前の記事で触れた「象のモデル」の問題について振り返ってみる。ここに自らの不見識を晒すのだが、、かつてこんなツイートをした。
「デザイン者」は、この意味において、ドメイン限定ながら"神"に近い。
— たなかこういち (@Tanaka9230) May 20, 2019
「デザイン者」はモデルを（残念ながら"イデア"ではないものの）、まさにクリエートするという意味において、「世界感の創造主」なのだ。（残念ながら世界そのものの創造主ではないものの）
※リンク先を開いて、連ツイの先頭から辿っていただきたい。
たしかに厨房やホールという業務の現場だけを見ていても、"統合モデル"は出てこない。なにかしら視座の切り替えが必要なのは確かである。そういう視座を持つことを比喩として"神"と表現した。これに対して、杉本氏から次のようなお叱りをいただいてしまった。
「ドメイン・エキスパート」という超人的存在は存在しないのだ、という気づきは素晴らしい。でもそれを、神の目を持つ「超人的デザイナー」で置き換えたら、せっかくの気づきの価値が半減すると思います。
— 杉本啓 (@sugimoto_kei) May 20, 2019
表現の稚拙さは認めるしかないが、しかし正直何かしらの超越的視座といった想定はやっぱり必要なのではないか、という思いは変わらずにいた。
しかしこの考えは丸ごと誤っていたと今回はっきりと気付いた。実は、"何かしら超越的視座"と捉えていたものは、単に当該事業を成り立たせようと考えていた事業者の事業設計の問題なのであった。仮に開発者が事業当事者以上に上手な設計ができたとしても、それも単にそういう事業モデルをよりうまく考案しただけであり、どこにも超越性など無かったのだった。
このことは同時に、統合モデルの見い出しにおいて、（一つのイデアだろうが二つのイデアだろうが、）イデア的存在を探求するようなアプローチ自体が無効であることをも示唆するであろう。統合モデルも、なにせ人が構想し人が作るものの範囲だということだ。
これでようやく安心できる。厨房やホールといった現場コンテキスト横断的なモデルを作り出す行為に対して、どうしても"超越的視座"のようなかたちでしか説明ができなかった。そこに、事業構造を持ってくることで、人の営みの範疇に収めることができたのだ。
なぜ帳簿システムが必要なのか？
SoRとは事象を記録していくことが役目だと言われる。「複写式伝票」も、注文の発生事実を記録することが主要な役割だと言える、その注文の発生事実を、ホール側はホール側の業務遂行のために、厨房側は厨房側の業務遂行のために異なる方法で活用している。杉本氏のいう「帳簿システム」とは、この「事象発生の事実記録」をまさに実施しているシステムと言える。「事業のモデル」とは、即ち「事実記録をしている帳簿の集合体」なのだと帰結できるだろう。
であれば、RDBが延々と使われ続ける背景理由も分かってくる。つまり、事業のモデル＝帳簿システムを実装するための業務基盤として、RDBのリレーショナルモデルは、あまりにも完成されているのだ。
前の記事では、事業のモデルとは、帳簿システムとして実装できることを言った。だがまだ疑問は残る。帳簿システムはどのように必要だというのか？
ここでPHP Mentorsから次の記事を参照する。
上記表はPHP Mentorsの記事からの引用である。一番上の段がPolicy、中段がControl、下段がOperationに対応する。この記事によると、Policy-Control-Operationとは、「経営、管理、業務という3つのタイプで、これは企業や何らかの組織がある目的を持って活動する時、つまり経営活動が行なわれる時に、さまざまなレベルで表れる構造」とのこと。
この表を見ると、帳簿とは、経営活動におけるこのような構造の各階層の、とくに中段〜下段の、情報を記録したもの、と理解できる。
さらには上記記事で参照している次の佐藤氏（@satou_masami）の記事では、「組織過程」、「管理過程」、「事業過程」として示されている。
佐藤氏の記事から何点かフレーズを引用する。
管理過程が事業過程を計画・管理（management）しているということです。
...
管理過程を対象にして作った「モデル」を起点にして事業過程を確認するのが、理論編-2 で述べた「意味論」の領域です。
...
ひとり（あるいは、複数の）システム・エンジニアが「事業過程（第一世界）」そのものを対象にして、エンジニアの視点・解釈で作った「第三世界（構造）」など「無意味（ナンセンス）」だということです。
...
もとよりControlレイヤー≒管理過程としてのモデルが無ければ、Operation≒事業過程の意味など取れないという。あるいは、Operation≒事業過程だけから"勝手な想像"でモデルを組み立ててもナンセンスだと言う。
僕も含めて、現場開発者で、目の前のオペレーションを分析することには注意を払っていても、事業を成り立たせている上部構造までには意識を向けていない方、多いのではないだろうか。いやはや、"超越的視座"といったものを想定したことなど赤面ものでしかない。
◇
以上の構図から次のようなことが読み取れるであろう。
- 帳簿システムとは、Operation≒事業過程やControl≒管理過程の記録、ということだった。
- その記録は、 Operation≒事業過程やControl≒管理過程を滞りなく回すためのみならず、Policy≒組織過程へ情報提供するために必要と言える。
また、事業を営んでいる場合に直接的に生成される「データ」の源は、Operation≒事業過程においてであると言えるだろう。それをControl≒管理過程としてもともと定めているモデルに当てることで、「情報」として活用できるようになる、というところだろう。さらに、Policy≒組織過程に上げていくことで、事業上の意思決定＝モデルの変更の材料、となっていくということまで見て取ることができる。
SoIとSoCとSoR
「SoI」および「SoC」という用語について考察する。
「SoI (System of Insight)」は、結構あちこちで見るようになったキーワードである。概ね従来からの「BI」、もしくは「（OLTPに対する）OLAP」に等しく、SoEやSoRに揃えた用語として登場したものと受け取っている。多少付け加えるならば、OLTP（≒SoR）が起源となる情報だけでなく、SoEにおける利用者の直接的な行動情報といったものもSoIは扱う、と言う点が"OLAP時代"とは異なるか。
もう一つの「SoC (System of Control)」は、あまり見ないキーワードで、こちらの発表およびツイートで初めて見知った。
ありがたいつっこみです！当日は10分しかなかったので細かい話はできなかったのですが、System of Controlの出典はこちら↓で、READYFORではもう少し単純化した概念（BPMNで表現されるようなワークフローに相当するレイヤー）として使っています。https://t.co/ye0VwlrCD1
— いとひろ@READYFOR (@itohiro73) February 24, 2020
紹介される元記事を見ると、概ね次のような概念のようであると受け取った。
「SoEとSoRの間に入って、認証・認可、ワークフローやデータフロー、プロセスやルール、といった対象についての、IntegrationとControlを担う。」
伊藤氏（@itohiro73）は、ツイートにあるように「ワークフローに相当するレイヤー」として解釈されているとのこと。
◇
さて"SoX"ワードが集まったが、、これらは、Policy-Control-Operationや組織過程－管理過程－事業過程といった構図に妙に良くマッチすると思った次第である。
| Policy | 組織過程 | System of Insight |
|---|---|---|
| Control | 管理過程 | System of Control |
| Operation | 事業過程 | System of Record |
2020年の論理アーキテクチャー理解は、巡りに巡って、DOA時代からの概念に舞い戻ってきた様子である。