アーキテクチャの方法論 - 3 層フラクタルアーキテクチャのデモ#
#記事 / 完了 / 公開済み
#アーキテクチャ
#3 層フラクタルアーキテクチャ
実践は真理を検証する唯一の基準です
私たちは階層化された方法を持っていますが、この方法は有効ですか？
いくつかのシナリオを仮想して、この方法が私たちの問題を解決できるかどうかを確認してみましょう。
例として、アプリ開発を考えてみましょう。
通常、最初は単純なビジネス要件しかありませんので、ビジネスに焦点を当てます。
私たちは、コアレイヤ、サポートレイヤ、アプリケーションレイヤを持っています。
サポートレイヤには、ビジネスに関係のない技術、フレームワーク、ツールなどの共通のライブラリや共通のコンポーネントが含まれます。
アプリケーションレイヤは、ビジネスレイヤで定義されたコンポーネントを統合します。
ビジネスレイヤは、コアのビジネスロジックを担当します。
![[Screen Shot 2020-12-21 at 09.02.27.png]]
ビジネスの成長に伴い、プロジェクトに H5 開発ページの機能を導入したいと考えています。この機能はネイティブのページ機能とは異なり、基盤として WebView のコンテナが必要です。
H5 の開発に注力する場合、WebView のサポートが必要です。
したがって、ビジネスレイヤでコンテナに焦点を当てます。
コアレイヤはコンテナレイヤであり、ネイティブビジネスコンテナと H5 ビジネスコンテナを提供します。
アプリケーションレイヤは元のビジネスレイヤですが、コンテナはビジネスのサポートに依存しています。
サポートレイヤはコンテナの基礎レイヤです。
![[Screen Shot 2020-12-21 at 09.02.38.png]]
今、異なる顧客がいて、異なるインターフェースと機能をカスタマイズしたいと考えています。
機能のカスタマイズに焦点を当てます。
コアレイヤはカスタマイズレイヤです。
サポートレイヤは元のビジネスレイヤですが、カスタマイズは元のビジネスに基づいています。
アプリケーションレイヤはカスタムアプリケーションレイヤです。
![[Screen Shot 2020-12-21 at 09.08.41.png]]
これで全体の階層を見てみましょう。
![[Screen Shot 2020-12-21 at 09.19.57.png]]
進化の観点から見ると、最終的な階層がどのように形成されるかは非常に明確ですが、最終的な階層だけを見てもなぜこのようになるのかは理解しづらいです。
もちろん、階層の分解は続けることができますが、3 層フラクタルの方法はアーキテクチャの進化をより明確かつ理解しやすく表現しています。