Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

Template:OutSystems/OSLanguageSwitcher
Language:

 

 

 

 

 
OutSystems

OutSystemsを使用したドメイン駆動設計

OutSystems 11では、ユーザーがドメイン駆動設計に基づいてドメインアーキテクチャを作成できる機能がいくつか導入されました。

DDDを導入または活用するタイミング

ドメイン駆動設計の機能を導入または活用する適切なタイミングはいつでしょうか。これは良い質問ですが、ケースによってそれぞれ異なるため、一般的には答えにくい質問です。

最初から活用を検討してもかまいませんし、複雑化した状況を見て検討し始めてもよいでしょう。

DDDが非常に適している場合もありますが、そうでない場合もあることに留意します。アプリケーションのドメインはそれほど複雑でなくても、逆に技術的にかなり複雑になっている場合は、DDDはあまり有効ではありません。

DDDを活用するタイミングを示すクアドラント

ドメイン駆動設計の形成

OutSystemsでのDDDアーキテクチャの形成は、主に以下の3つの手順で行います。

設計プロセス

複雑なシステムのアーキテクチャを設計する場合、最適なアプローチは「分割統治」であり、ビジネスをより小さなブロックに分解します。この分解は、業務または製品系列に基づいて行います。これは反復プロセスであるため、ブロックが適切な粒度になった場合にのみ停止する必要があります。

反復分解プロセスには、以下の3つの手順があります。

  1. ビジネスのマクロプロセスと基準を特定します。

  2. 事前定義された以下の基準を使用して、各マクロプロセスを分解します。

    a. 業務

    b. その他の機能基準

  3. 目的とするレベルの粒度を達成しているかどうかを確認します。達成していない場合は、分解を続行します。

専任の総合チームを設置する

所有権、管理性、ライフサイクルの独立性を促進するために、設計プロセスでドメインを特定でき次第、そのドメインを所有するチームを割り当てる必要があります。

軽量で安定したサービスインターフェイス

パブリックインターフェイスは、各チームによって各ドメイン内に作成される必要があり、他のドメインにサービスを提供します。これにより、変更があった場合に、無関係のドメインへの影響が最小限に抑えられます。

コンセプトとOutSystemsへのマッピング

ドメインの種類

ドメインは3種類あり、それぞれ独自の目的が定義されています。

  • オーケストレータドメイン - オムニチャネルとしてイメージで表現されるため、エンドユーザーは独立した業務を一元的に捉えることができます。

  • 垂直ドメイン - 業務に対応します。

  • 水平ドメイン - 複数の垂直ドメインで共有できる再利用可能なコアビジネスサービスを提供します。

モノリスとマイクロサービスの長所を生かす

OutSystemsでは、モノリシックアプローチとマイクロサービスアプローチをバランスよく両立させる解決案でアーキテクチャを設計できます。両者の長所をすべてアプリケーションの設計と開発に生かすことができます。

ドメイン内

同じドメイン内では、要素間の密結合が維持されます。

これは、以下を実現することで、密なプロセスにメリットをもたらします。

  • プロセス内通信

  • 共通のデータベーストランザクション

ドメイン間

ドメイン間では、疎結合の関係が維持され、以下の2つの部分に分割されるドメインAPIが提供されます。

  • パブリックエンティティ

コンシューマが表示、検索、他のエンティティとのマッシュアップを実行できるようにする読み取り専用エンティティ

  • サービスアクション

データトランザクションと詳細の取得

複合的なロジックやトランザクションを調整するために、例外として、水平ドメイン間に強い関係を結ぶことができます。

水平方向の基盤アプリケーション

非機能要件を伴う水平方向の基盤アプリケーションとの強い結合は、他のドメインから直接参照できます。これは、テーマ、UIパターン、プラグインに役立ちます。

ドメインアーキテクチャ

適切なドメインアーキテクチャによって、データの分離、所有権の促進、変更の影響の低減が実現します。

また、提供されているサービスの現状について組織が理解を深めたり、そうしたサービスをより適切かつ簡単な方法でビジネスにマッピングしたりする場合にも役立ちます。

ドメインを分離する方法

ドメインアーキテクチャに着手するには、単純なものから開始し、必要に応じて複雑さを増していくことが推奨されます。そのため、まず既存の機能を活用することが適切な方法です。

以下の図のように、複雑さが増し、チームの構造やモノリスが増えるにつれて、アーキテクチャを見直して、新しいパターンを実装する必要があります。

これを実現するには、いくつかのルールに従う必要があります。

ドメイン検証ルール

ドメイン間の参照オブジェクトは、以下に示すルールの範囲内で許可されます

()構成によって設定されたオプションの参照

垂直ドメイン間で許可される参照

  • サービスアクションやストラクチャのような弱い参照(オプションで、構成時にエンティティへの参照が許可される)

水平ドメイン間で許可される参照

  • サービスアクション、ストラクチャ、エンティティのような弱い参照(オプションで、構成に応じてサーバーアクションへの参照が許可される)

  • 垂直ドメインと水平ドメインのサービスアクション、ストラクチャ、エンティティ間の弱い下方参照

垂直ドメインから水平ドメインに許可される参照

  • サービスアクションやストラクチャのような弱い参照

  • 垂直と水平の間の強い参照(参照される要素が基盤アプリに含まれている場合)

ドメイン間の残りのすべての関係は、アーキテクチャによる成果物とみなされ、許可されません。

注意事項として、「ドメインの種類」セクションのオーケストレータドメインは、ドメインの関係を検証する際に垂直ドメインとみなされます。

アーキテクチャの原則

同じArchitecture Canvasの原則がドメイン内とドメイン間の両方に適用されます。

高度なアーキテクチャパターン

場合によっては、ビジネスユースケースをサポートする高度なパターンを実装する必要があります。

このセクションでは、ドメインアーキテクチャに関連する最も重要なパターンについて説明します。

複数のトランザクションの管理

ユーザーがカスタム例外の処理や様々なAPI連携について頭を悩ませることがないように、別のドメインに含まれる単一のトランザクションロジックでシームレスに調整することが必要になる場合があります。

これを実現するには、以下のように複数のサーバーアクションを単一のトランザクションに一元化するサービスアクションを作成します。

データのマッシュアップ

頻繁に変更されないデータをマッシュアップする必要が生じた場合は、以下のようにクエリモデルパターンを使用できます。

このクエリモデルでは、データのサブセット(リスト機能や検索機能を提供するために必要なデータ)のみを公開する必要があります。これにより、データベースモデル全体を公開する必要がなくなり、複雑な同期もなくなります。レコードの詳細の取得やレコードの更新といった操作には、サービスアクションまたはREST APIを使用します。

ドメインアーキテクチャを検証する方法

アーキテクチャを検証するために、OutSystems Forgeで入手可能なDiscoveryというツールがあります。

  • Was this article helpful?