2024/11/16追記：ODC Studio 1.4.31でRoleをPublicにする機能が追加された。この記事の解説はそれ以前に書いたもの
Architecture Specialization (ODC)はODC向けのアーキテクチャ知識を認定する試験。
この試験の発表とともに、ODCを対象とするProfessional認定条件が発表された。Architecture Specializationはその条件の1つ。受験の前提がAssociate Developer (ODC) で、2024/4時点では未発表の残り2試験を合格すると、Professional Web Developerとして認定される。
試験情報のPDFと一緒にダウンロードできるサンプル問題を解説する。
全部で10問で、この記事では1問目-5問目が対象。
Architecture Specialization (ODC)のサンプル問題について解説 2/2 (#6-#10)
サンプル問題は、
https://www.outsystems.com/learn/certifications/
の、「Architecture Specialist (ODC) 」項目のリンク「Exam Details」でダウンロードできる資料から。「Sample Exam」がついているのファイルが該当する。
ここでは2024/4にダウンロードしてきたファイルを使って解説していく。
サンプル問題は英語しかなかったので、この解説は英語版を見ながら書いている。
各問題のタイトルは、Details SheetのCategories & Topicsで、問題に対応していそうなものを選んでいる。
1 Deployments and Configurations
あるAppで定義済みのRoleがある。このRoleを他のAppで利用したい場合に、
- Roleをどう定義するか
- 定義したRoleをどうユーザーに割り当てるか
という問題。
これは、Architecture Fundamentals in ODC - Configurationsという動画の、2:20あたりに解説がある。
ODCではRoleをPublicにできないため、取りうるオプションは
- Roleを定義したAppがService Actionを公開し、指定ユーザーがRoleを持つかどうかを返す
- 同じ名前のRoleを各Appに定義し、ODC Portalでユーザーに両方のAppで定義されたRoleを付与する
というもの。前者は、Role利用Appが増えるに従って、Roleを定義したAppへの負荷が高まることから推奨されていない。
というわけで、後者に合致する選択肢Cが正解。
2 Reusing Elements
各選択肢を見ていく。
A. ✕：AppはLibraryの要素を参照できる（強い参照になる）だけでなく、他のAppの要素も参照できる（弱い参照になる）
B. ✕：これは逆で、Libraryの要素を参照するときは、必ず強い参照になる
C. ✕：これも逆。Appの要素を参照すると弱い参照
D. ◯：正しい。LibraryはLibraryの要素のみ参照できる。Appが公開しているEntityやService Actionを参照することはできない
というわけで正解は選択肢D。
Libraryを参照すると、
- その参照は強い参照になる
- 強い参照の場合、Libraryはコンパイルされ、ConsumerのApp内に組み込まれる
- 呼び出すと、オンメモリで実行される
Appを参照すると、
- その参照は弱い参照になる
- 弱い参照の場合、参照先のAppは、Consumerとは別のApp
- 呼び出しは、HTTPS経由
- LibraryはAppを参照できない
3 Disclose
Architecture Design ProcessのDiscloseのステップで、構築しようとするアプリケーション内のConceptを特定するときに、参照する要素「でない」ものはどれか、という問題。
Architecture Fundamentals in ODC - Architecture Design Processの3:00あたりのスライドに必要な情報が載っている（番号はこちらでつけた）。
- Business requirements, processes, user stories, personas and roles
- Information architecture
- Non-functional requirements, integration technologies
- User experience expectations
選択肢を見ていくと
A. ✕：含まれない
B. ◯：1に含まれる
C. ◯：1に含まれる
D. ◯：3に含まれる
よって、正解は唯一✕になる選択肢A。
この問題を解く際には注意事項として、同じテーマを解説するドキュメント、Building a well-architected appを参照しても正解にたどり着けない（2024/04/07時点）。
4 Disclose/Organize/Assemble
O11のアーキテクチャ設計プロセスでも含まれていた、Disclose->Organize->Assembleの各ステップについて聞く問題。#3の問題と同じくドキュメントの方のBuilding a well-architected appを参照しても回答にたどり着けない。動画のArchitecture Fundamentals in ODC - Architecture Design Processを見る。
A. ✕：Disclose開始時点で主要なConceptを見逃していても、作成するアーキテクチャの設計図に影響がないというようなことが書いてあるが、恐らくそうではない。主要なConceptの見逃しは、アーキテクチャ設計の重要な問題となり、後で発覚すると設計のし直しなど影響も大きい。また、3ステップの繰り返しは、OrganizeやAssemble中で発覚した点についてDiscloseに戻るので、最初の段階で漏れていると見逃しになりかねない
B. ✕：Bounded Contextを発見するのがOrganizeのステップ。よって「During the Organize step, the previously identified bounded contexts」の段階で正しくない (Bounded Contextsは事前に識別されるのではなく、まさにOrganizeステップ中で識別される）
C. ✕：Assembleステップでは、Organizeステップで識別したBounded ContextをBusiness OwnerやBusiness Sponsor、開発チームとマッピングする
D. ◯：Bounded Contextを識別する際にdomain expert boundariesやbusiness processesに着目してグループ化する点については、動画のスライドの「Grouping Contexts」というタイトルのページを参照
というわけで正解は選択肢D。
5 Assemble
A. ✕：オーナーシップを明確にするのはAssembleステップ
B. ✕：Business Ownerは複数のAppを持っても良い。1つのAppが複数のBusiness Ownerを持つのは良くない。Business OwnerはそのAppの「Go to person」であるため、複数いると、責任が曖昧になったり要求項目の優先度で問題になったりする
C. ◯
D. ✕：特にこういう制限は言及されていない
正解は選択肢C。