O11からODCへの移行についてのドキュメントを読んで見る（2023/12/16時点）

O11からODCへの移行手順とツールについて案内するドキュメントがついに公開されたので、読みながらコメントしていく。この記事は2023/12/15-16にかけて作成。

読んでいる時点でのドキュメントの構成はこんな感じ。

全体的な感想

全体的な流れとして、

1. O11のアプリケーションをリリースされるツールで解析し、
2. 開発チームでODCに移行できるように修正し、
3. ODCに用意される機能でプログラムとデータを移行する

というもの。

1.でO11のアーキテクチャ設計の推奨事項（Architecture Canvas、DDD、サービス志向設計）をきちんと踏んでいる、あるいはこの移行作業の中で踏むことが前提となっている。

個人的な観察の範囲では、Architecture Canvasをきちんとやり切っているような組織は少なく、さらにOutSystemsのいうDDDを実行している組織となると、ほぼないのでは無いか？　と思う。

そうなると、この移行ステップをそのまま実行するのには困難が予測される……と思う。OutSystemsのDDDは、本来のDDDよりかなり簡素化したものになってはいるが、実践するにあたって、今OutSystemsがリリースしている情報だけでできるのか、あるいはDDDの一般書式等で学習する必要があるのか、で困難さがだいぶ変わりそう。

ODCはマイクロサービス設計されることを前提に作られていると思うが、別にDDDや厳密なマイクロサービス設計をしなくても開発はできると思うので、この移行ステップもそれを回避できる道があるのならよいのだが。

現段階では、

• O11で厳密にOutSystemsが推奨するアーキテクチャ設計をやっていた組織であれば比較的楽に移行できそう（そんな組織はほとんどないと思うけど）
• そうでない組織は、移行ツールを利用できるようにするのにかなりの工数がかかりそう（アーキテクチャ設計の変更、それに伴う各種設計・実装、テスト）
• 工数がかかるので工期もかかる。新しいアプリケーションはODCで作成しつつ、横で準備を進め、少しずつ移行していく「Coexistence」方式をとることになりそう

という印象を受けた。

OutSystems 11 to ODC migration

O11からODCの移行ドキュメントの親となるドキュメントで、全体的な流れを説明するもの。

移行に使う諸々のものをまとめてMigration Kitと呼ぶ。ベストプラクティス、ガイドライン、ツールからなる。

移行は、以下の4つのステージで行われる。

1. 1. O11のアプリケーションを評価する（ツール：Migration Assessment Tool)
   2. 評価結果を受けて移行に適した形にプログラムを修正する（ツール：Service Studio。つまり普通に開発によって修正するということ）
   3. 修正したO11プログラムを移行する（ツール：ODC Migration Console）
   4. データを移行する（ツール：ODC Migration Console）

やはり、OutSystemsとしては、クラウドネイティブアーキテクチャを活かすために、マイクロサービス設計やDDDを利用した設計を「しなければならない」と考えていそう。

ステップ3では、eSpaceとExtensionがODCのものに変換される。そのためのツールが提供される予定。

Prepare O11 application architecture

前項のステージ2、プログラムを移行に適したものに修正する手順の説明。対象読者は、

O11開発のアーキテクト。

以下の手順で行う。O11のアプリケーションの時点で、O11のドキュメントで推奨されていたアーキテクチャ設計をそのままやる想定になっている。

1. Architecture Canvasを適用する（ドメインにまとめやすくするため）
2. domain-driven architectureを取り入れ、小規模の疎結合のAppのセットに分割する
3. アーキテクチャを検証する。Discoveryを利用すると書かれているが、AI Mentor Studioでもよいのでは
4. O11のドメインをODCのAppとLibraryにマッピング
5. リファクタ：O11としてのベストプラクティスに合わせる
6. リファクタ：ODCで利用できるように修正
7. 残ったどうしても変換できないものに対処する

O11におけるDDDについては、以前書いたOutSystemsのDDD情報まとめを参照。

Map O11 domains to ODC apps and libraries

O11でDDDを導入していた前提で、DomainをどうODCのApp/Libraryにマッピングするかを説明する。

• Vertical Domain -> App
• Vertical Domainでしか使わないFoundationレイヤがあれば、Libraryにマッピング
• Horizondal Domain
  • 共通ビジネスロジック、技術（たぶん非業務という意味）サービス、データ -> App
  • Foundation -> Library

Convert O11 architecture blueprint to ODC architecture blueprint

ざっくりいうと、移行しようとするO11のアプリケーションに対して、ODCのアーキテクチャ設計のプロセスを実施する。それによって、O11のアーキテクチャ設計をODCのアーキテクチャ設計にマッピングする。

About refactoring O11 apps to be ODC compatible

各要素毎にO11の要素をどうODCの要素にマッピングするかを書いている。2023/12/16時点ではどの記述も大変簡素なものになっており、有効なガイダンスの説明が無いものもある（BPTとかSystem entitiesとか）。

将来的には以下のいくつかのリファクタリングを自動化する予定だが、現在は全て手動で行う必要がある。