記載内容について
気がつけば3月となっていましたが、あけましておめでとうございます。今年もよろしくお願いします。
今回からArchitecture Specialistに向けた学習内容を備忘録として連載することに決めましたので張り切っていきます！
Architecture Canvas
Outsystemsにおけるアプリケーションのアーキテクチャー設計をサポートするフレームワークで
下記画像の通り３レイヤーで構成されています
Architecture Canvasの３レイヤー
Foundation（基盤レイヤー）
外部システムのコネクタ、ライブラリ、再利用可能なUIパターン、テーマ等のビジネスに依存しない再利用可能な非機能モジュールが全て含まれるレイヤー（ビジネス固有のサービスを含めてはいけない）
ビジネスに依存しない非機能要件のためあらゆるビジネスドメインで再利用することができるレイヤーになっています
Core（コアレイヤー）
コアビジネスサービスを格納します。依存関係、ビジネスルールなどのビジネスコンセプトに関連するサービスが含まれます。こうしたコアビジネスサービスはシステムから独立させ、下位にある基盤レイヤーとの連携の詳細を抽象化する必要があります
コアサービスに加えて、ビジネスルール、トランザクション、データすべてが含まれる。外部システム用のAPIを用意するのもありです。Rest、SoapなどあらゆるタイプのAPIを使用して内部と外部の接続を定義します。
End-User（エンドユーザーレイヤー）
サービスを入れてはいけないレイヤーでユーザインターフェースとプロセスを通じてユーザーインタラクションを全てサポートします。
Architecture Canvasを使用するべき理由
使用するべき理由は主に3つあり、テストにもよく出るようなので覚えておく必要があります
・再利用可能なサービスの適切な抽象化が促進される
・依存関係を理解して明確に定義することでライフサイクルの独立性を最適化しやすくする。
・変更の影響を最小化する（保守がしやすくなり効率的にアプリを更新できるようになる
エンタープライズエコシステムにおけるOutsystems
Outsystems自体がエコシステムにある独立したテクノロジーなので実際に業務で使用していくためには他の既存の社内システムやクラウドベースのシステムとの連携が必要になります。
これらとの連携をするための外部システム向けの連携サービスを作成する必要があり、このサービスがデータの正規化、エラー処理、認証処理などの複雑な連携を抽象化する点で役に立ちます。
次回
横文字ばかりで難しいですが自分が意味を理解しきれていない単語にはリンクを貼ったりコメントを残しているので確認していただけると嬉しいです！
次回はアーキテクチャの設計プロセスについて記載していこうと思います。
コメント