おかげさまでネット上では『OpenDolphin -wikipedia 風解説-』がなぜか支持されているようだ。
元々は、ドルフィンのソースコードを眺めていた時に、（従来は）開発者認定されていない人の署名を見つけて、ちょっとびっくりしてそこらへんのことをまとめておいただけの記事だった。
が、その後も報告が断続的に集まり続け、その都度書き足していったら、現在の形態になったという経緯だ。
こういう斜めから入ったような記事でも、それなりに読まれたりするものなのですね。
意外な気もするが、納得できるところもある。
ところで、OpenDolphin の件で若い人から言われて印象に残っているのは、
現在の Java や JakartaEE の各仕様を使えば数行で処理できるところを、何でその十倍くらいのコードで（しかも）不自然に処理しているんですか？
という指摘だ。
正直、きっつ。。
まあ、一言で言えば、データ構造修正とコストとの兼ね合いの問題ですね（汗）。
データ構造の限界やその処理方法の古さは、われわれも認識はしていたが、ひとたび、データ構造に手を入れ始めると、それを内部的に処理している部分も変更せねばならず、そのコストが（修正した）利益に見合わないとみていた、というのが答えといえば答えになるでしょうか。
なんか、うまい説明になってないか。。。
ここら辺で興味深かったのは、某先生の判断と立ち回りだ。
ギリギリまで OpenDolphin 2.7 のデータ構造は維持し続け、変え時と見たら一気に変えてしまった。
（ここら辺の流れは、ここあたりから始まる一連のツィートを参照。）
この「変えて」しまったものが DolphORCA なんだが、設計の基本コンセプトからしてドルフィンとは大きく異なっている。
DolphORCA で採用された三層クラサバ構成に関しては『DolphORCA と三層クライアントサーバシステム』が良い案内になっている。
また、（直接、DolphORCA には触れられていないが）電子カルテ系と画像系のデータ構造の相性の悪さに関して
『なぜ、全国統一カルテは無理筋なのか？
-カルテ系と画像系のデータ構造の本質的な相性の悪さ-
(EHR-DICOM data structure mismatch)』
という記事にかなりわかりやすく書かれている。
DolphORCA のデータ構造は、これらの考察を踏まえてかなりシンプルで使いやすいものになっている。
ここら辺の分野に興味のある方はぜひ一読をすすめる。
が出ればとりあえず環境は構築されている。
