DolphORCA Ver1.3

SOA 領域は前回で目処がついた感があるので、お次は P 領域。

SOA 領域には、理屈の上で情報量に上限はないが、これは CLOB を使うことで解決できる。

カルテの P 欄の面倒くさいところは、項目(処方とか検査とか)の数が理屈の上で上限がないこと。
まあ、1回の外来で手技を20も30もやる先生はいないと思うが、ここを数量限定にしてしまうとなんか負けた感じがするので、意地でもそうはしなかった。
結局、カルテのドキュメントに相当するクラスの中に P の項目に相当するクラスを複数埋め込める設計にした。

DB から情報の取得→シリアライズ→画面への表示

あたりはできている。

あとは

・デシリアライズ
(逆順ができないと編集した P の情報を DB に記録できない)

・レセコンとの連動

あたりが課題。

連動させるレセコンですぐに思い浮かぶのは ORCA だが、ORCA 限定にはしたくないなあ。

ところで、私事ですが、変な感じで擦り寄ってきた胡散臭い感じのビジネスパーソンの方々はバッサリ切りました。
「先生、あとどれくらいかかるんですか?」とか聞くのは反則だと思う。
こんなの義務でもないし、とりわけそういった人々のためにやっているのでもなんでもない。
進行管理したければ、自分で調べればいいだけの話。
進行状況などオープンにしているし、それで工程数を予測できないのは素人レベルでしょう。
さらに言えば、最終的には html に書き出すので、本当にプロジェクトを先に進めたければ、フロントエンド周りのレイアウトやらなんやらは自分でやればいいだけの話。
そのためにバックエンドサーバーはフリーで公開しているんだが?

html なんて凝った機能を使わなければ、中学生でも書けるでしょう。

 

猪股弘明

 

OpenDolphin Ver7

OpenDolphin の JakartaEE 9.1, Java17 対応バージョンである OpenDolphin Ver 6 を関係者向けにリリースしたんだが、Java の EE 環境自体は JakartaEE 10 へと向かっている。

当然、OpenDolphin の JakartaEE 10 対応(OpenDolphin Ver7)も考えている。

が、これまでのように(EE 環境などの)仕様変更に伴いソースコードを単純に再調整する、という風にはならなそう。

内輪向けにプロトタイプバージョンなども披露しているが、こちらの方がどうも評判がいい。

以前から、三層クラサバ化などは図(↓)などを提示した上で提案していたのだが、具体的な形が見えた方がより反応がいいようだ。

まあ、これだと確かに概念的すぎるか。

具体的にバックエンドサーバー・フロントエンドサーバーがどのように動くか雰囲気掴んでもらうために、以下のような図を提示した。

API の出力を単純にブラウザ上に表示させているだけなんだが、どういうわけかこちらの方がウケがいい。

上の場合だと id=3 のカルテを表示してね(データベースから取ってきてブラウザ上で表示してね)ってことなのだが、この時、このリクエストやサーバーからのレスポンスは

ブラウザ⇄フロンエンドサーバ⇄バックエンドサーバー⇄データベース

という感じで流れる。

この流れが視覚的にわかりやすいってことなんでしょうか。

一般の人に基本設計がどうしただの REST がどうしただのと言っても通じないもんなんだなあと(笑)。

 

猪股弘明