最近、新しく追加された試験「Architecture Specialization」のサンプル問題が公開されています。

各問題を確認し、回答に必要な資料へのリンクと解説をまとめます。

全部で10問で、この記事では1問目-5問目が対象。

試験問題は、
https://www.outsystems.com/learn/certifications/
の、「Architecture Specialist (OutSystems 11)」項目のリンク「Exam Details (.pdf)」でダウンロードできる資料から。

日本語対応

アーキテクチャ設計周りの資料は日本語化が遅れているようです（2021/01/16現在）。
試験勉強するのにどうしても英語の資料を当たらなければなりません。

以下のコースは、この分野で最も基本的な情報がまとまっており、教材は日本語化されています。
アーキテクチャフレームワークを使用したアプリ設計

注意点として、

動画自体は英語のまま
OutSystemsバージョン10の頃の動画なので、用語が古い（LibraryレイヤーはFoundationレイヤーに、4 Layer CanvasはArchitecture Canvasに改名されている）
Canvasの改名に伴い、Orchestrationレイヤーは無くなっている
右上のドロップダウンリストがEnglishになっていたら日本語に変更する

1 Architecture Canvasを利用するメリット

Architecture CanvasはOutSystemsで進められているアーキテクチャ設計用の図法かつ、それを利用した設計方法のことです。
以前は4 Layer Canvasと呼ばれていました（OutSystemsバージョン10まで）。

Architecture Canvasをなんのために利用するかという設問です。
この点については、以下の資料の教材のスライド「キャンバスを使用すべき理由」に記載があります。
4 Layer Canvas

アーキテクチャ設計の高速化（体系的なアプローチ）

共通認識の促進（ビジネスユーザーと開発者）
アーキテクチャの検証の簡素化（ツールによるサポート）

これをもとに各選択肢を検討していきます。

B：自動的な方法を提供しているわけではない（設計作業が必要）ので☓
C：微妙な部分もありますが、ビジネスユーザー間の共通認識だけでなく、「ビジネスユーザーと開発者」なので☓
D：理由のスライドにある通り、「検証の簡素化」つまり検証自体は必要なので☓

というわけで回答はAですね。この回答はスライドの1番目と2番目をまとめたものになっている。

2 モジュール構成の指針

問題は、無関係な概念（concepts）を1つのモジュールにまとめるべきか？
選択肢はこれに対し、Yesで回答するのが2つ、Noで回答するのが2つ。
Yes/Noに対する2つの選択肢はそれぞれ別の理由を挙げています。

以下の資料の教材のスライド「モジュールの組み立てに関する基本原則」に記述があります。
アーキテクチャ設計プロセス

密接に関連しているコンセプトを結合する

複雑すぎるか、それぞれのライフサイクルが異なるコンセプトは結合しない
再利用可能なロジックは、統合ロジックから分離する（コンシューマは統合ロジックを意識していない）

統合ロジックとは、原語が「Integration Logic」で外部システムと直接接続するロジックのこと。
というわけで、「密接に関連しているコンセプトを結合する」わけですから、問題に対する回答は「No」。

その上で理由を検討しましょう。

B：これについてはそのとおり。OutSystemsは参照しているモジュールの変更を検知し、参照を更新するように要求してきます（別に要求がなくてもそうすべきではある）。aという概念とbという概念が1つのモジュールに含まれていてこれらが関係ない場合、aしか参照していないモジュールがbの機能追加などでリリースを要求されるとしたら具合が悪いですね
D：上のa/bの例えでいうと、aとbの両方を必要としているなら、参照している側としては1つにまとまっているのはむしろ便利なので☓

3 参照の強弱（OutSystems 11で導入された）

問題は、「OutSystems11からScreenへの参照は弱い参照となり、業務に関連するScreenをFoundationレイヤーに配置する事が勧められるようになった。このときArchitecture Canvasの検証ルールへの違反は発生しない」。

参照の強弱概念

OutSystems11から導入された概念です。10までは、この概念がないために、Screen（画面）参照をArchitecture Canvasのルールに違反せずに行えませんでした。廃止されたOrchestrationレイヤーはルール違反せずに画面参照を行うのが主な目的でした。

弱い参照の場合、参照されているモジュールへの変更が「インターフェイスへの変更を伴わない、実装のみの変更」である場合、参照元のモジュールの再パブリッシュが不要です。
以前Qiitaに書いた記事：強い依存関係と弱い依存関係

というわけで、「OutSystems11からScreenへの参照は弱い参照となり、」の部分は正しい。

業務に関連するScreenを配置するレイヤー

ここで、Architecture Canvasの各レイヤーの概要を確認してみます。
再び、4 Layer Canvasの教材のスライドから。この資料は古いので、ライブラリはFoundation（ファウンデーション）に読み替えて下さい。

「4 Layer Canvas（4LC）」スライドに図が載っています。

End-Userレイヤー：サービスなし。UIとプロセス（エンドユーザーに機能を提供）

Core-Businessレイヤー：再利用可能なサービス。ビジネスサービス（ビジネスコンセプトに関するサービス）
Foundationレイヤー：再利用可能なサービス。非機能要件（外部システムに接続したりフレームワークを拡張したりするためのサービス）

ここから、業務に関連する要素を配置するのはFoundationレイヤーではないという判断ができますね。

以上から、問題文が間違いであり、全てのScreenが弱い参照であるが、業務に関係する画面はFoundationレイヤーに置くべきではないとしているDが正しい。

4 3つの検証ルール

問題は、「End-userレイヤーのモジュール間で同じレイヤー内での横参照をしている。この参照を取り除き、アーキテクチャの誤りを除去する一番良い方法はどれか」。

横参照についてですが、OutSystemsのアーキテクチャ設計では、出来上がった設計を検証するための3つのルールがあります。以下の資料の教材のスライド「検証ルール」に記載があります。

アーキテクチャの検証

上方参照しない

オーケストレーションモジュール間やエンドユーザーモジュール間で参照をしな
い
循環参照をしない

この問題はこの2番目が主題。
3つのルールについての解説（問題点と解決方法）は以下のドキュメントに記載があります（英語）。
Rule #2 - No side references among End-users or Orchestrations

ざっくり言うと

End-userレイヤーは、ユーザーに直接機能を提供するという役割上、多くのFoundation/Core Businessレイヤーのモジュールを参照している。

よって、End-userレイヤー同士で参照していると、そのモジュールからさらに参照されているFoundation/Core Businessレイヤーモジュールの修正に巻き込まれてリリースが必要になってしまうので避けるべき。

ということです。
ただし、弱い参照関係だと、参照先の変更が必ずしも参照元にリリースを要求しない。なので、End-Userレイヤー同士の「弱い」横参照については問題ないのでは？　という点が問われている。

明確な記述をドキュメント上で発見できていないのですが、Forumの投稿などでは、この通りであるらしいことが記述されています。
弱い参照の導入の意義に照らしてみても、実際問題はなさそうです。

というわけで、回答としては、End-userレイヤー同士の「弱い」参照関係は問題ないとするBが正解という流れ。

5 Calculation Engineを作成する目的

これは、動画のコースの一部に命名規則の一案を解説する回があるのですが、その中に説明がありました。

モジュールの命名

教材の「コアモジュールの命名規則」スライドに、Calculation Engineという種類のモジュールの命名規則（※）の案があります。ここに、Calculation Engineの解説として

BLは複雑な計算を実行する場合に計算エンジン（Engine）になる（請求計算エンジン、
保険シミュレータなど）。一般にエンジンはバージョンに依存する

とあります。というわけで、「複雑な計算をサポートするため」としているCが正解です。

※この案では、_Engというサフィックスをモジュール名につける