レイヤのページをご覧ください。ロジックが含まれています。ロジックはアプリに価値をもたらすものであり、アプリがデータを作成、保存、変更する方法を決定するルールで構成されています。多数のデータソースを含むことができるリポジトリで構成されています。クラスを作成する必要があります。アーキテクチャにおけるデータレイヤの役割。クラスは、次のタスクを行います。アプリの他の部分にデータを公開する。データの変更を一元管理する。複数のデータソース間の競合を解決する。アプリの他の部分からデータソースを抽象化する。つのデータソースのみを処理する役割を担う必要があります。オペレーションのためにアプリとシステムの橋渡しをします。このレイヤについて詳しくは、データレイヤのページをご覧ください。レイヤとデータレイヤの間に位置するオプションのレイヤです。ロジックをカプセル化します。すべてのアプリにこのような要件があるわけではないため、このレイヤはオプションです。複雑さに対処する場合や再利用性を優先する場合など、必要な場合にのみ使用してください。アーキテクチャにおけるドメインレイヤの役割。通常、このレイヤのクラスを「ユースケース」または「インタラクタ」と呼びます。つの機能を担うべきです。クラスを持たせることができます。このレイヤについて詳しくは、ドメインレイヤのページをご覧ください。コンポーネント間の依存関係を管理するアプリのクラスは、適切に機能するために他のクラスに依存しています。パターンを使用して、特定のクラスの依存関係を収集できます。依存関係の注入を利用すると、クラスの依存関係を構築することなく定義できます。ランタイムには、別のクラスがこの依存関係を提供します。パターンでは、クラスが依存関係を作成せずに取得できるレジストリが提供されます。したパターンでは、コードが重複して煩雑になることなく依存関係を明確に管理できるため、コードの拡張が可能になります。テスト版と製品版の実装を簡単に切り替えることができます。ライブラリを使用することをおすすめします。クラスの依存関係コンテナが作成されます。アプリの作成も例外ではありません。問題の解決方法は数多くあります。モード用にローカルで永続化するなど、重要なアプリで対処する一般的なシナリオにはさまざまなものがあります。以下の推奨事項は必須ではありませんが、ほとんどの場合これに沿うことで、コードベースの堅牢性を高め、テストとメンテナンスを長期にわたって容易に実施できるようになります。アプリのコンポーネントにデータを格納しないでください。レシーバなど)をデータソースとして指定しないでください。ポイントに関連するデータのサブセットを取得する他のコンポーネントとの調整のみを行う必要があります。コンポーネントの生存期間がかなり短くなります。クラスへの依存を減らします。依存する唯一のクラスにする必要があります。そこからアプリの他のクラスを抽象化すると、テストがしやすくなり、アプリ内の結合を軽減できます。アプリの各種モジュール間の役割の境界を明確に定義します。ネットワークからデータを読み込むコードを、コードベース内の複数のクラスやパッケージに散在させないでください。バインディングなど)を同じクラスで定義しないでください。アプリの推奨アーキテクチャに沿うと便利です。各モジュールからの公開はできるだけ行わないでください。モジュールの内部実装の詳細を公開するショートカットを作成しようとしないでください。短期的には時間を少し節約できるかもしれませんが、コードベースが発展するにつれて何倍もの技術的負債を負うことになる可能性があります。アプリの特別な部分に焦点を当てて、他のアプリとの差別化を図ります。コードを何度も書いてすでにあるものを作り直すのではなく、アプリを特別なものにすることに時間とエネルギーを集中させましょう。ライブラリやその他の推奨ライブラリを利用してください。アプリの各部分を個別にテストできるようにする方法を検討します。データベースに永続化するモジュールを簡単にテストできるようになります。か所に混在させたり、ネットワーク用のコードをコードベース全体に分散させたりすると、テストが不可能にはならないにしても、非常に困難になります。型は同時実行ポリシーに関する責任を負います。ある型が時間のかかるブロック処理を実行している場合、その型は適切なスレッドに計算を移動する責任を負います。その特定の型は、実行している計算のタイプと、その計算をどのスレッドで実行する必要があるかを認識します。型はメインセーフである(つまり、ブロックせずにメインスレッドから安全に呼び出せる)ことが必要です。データの関連性と新鮮さをできる限り維持します。モードのときでも、ユーザーがアプリの機能を利用できるようになります。すべてのユーザーが常に高速な接続を利用できるわけではなく、たとえ利用できるとしても、混雑した場所では受信不良が起きる可能性があることに留意してください。チームに次のような多くのメリットをもたらします。アプリのスケーリングが可能になります。多くの人々とチームが、コードの競合を最小限に抑えながら、同じコードベースで開発に寄与できます。オンボーディングに役立ちます。アーキテクチャによってプロジェクトに一貫性がもたらされるため、新しいメンバーが速やかにチームに適応し、短時間でより効率的に作業できるようになります。テストが簡単になります。優れたアーキテクチャでは、一般的にテストしやすいシンプルな型が推奨されます。適切に定義されたプロセスを使用して、体系的にバグを調査できます。アーキテクチャへの投資は、ユーザーにも直接的な影響を及ぼします。チームの生産性が高まることで、アプリの安定性と機能性が向上します。アーキテクチャの実装には事前の準備時間の投資も必要です。事前に社内の他の部門に対して実装を正当化するには、こちらのケーススタディが役立ちます。優れたアーキテクチャをアプリに実装した企業の成功事例が紹介されています。アーキテクチャを実証するものです。このガイダンスを実践するためにご利用ください。ライセンスに記載のライセンスに従います。関連会社の商標または登録商標です。