問題タブ [clean-architecture]

Uncle Bob Martin の「Clean Architecture」を使用して設計された Go プログラムで、ID の適切なタイプを見つけようとしています。

私は Uncle Bob Martin の「クリーン アーキテクチャ」に従っています。ここでは、コードが一連のレイヤーとして編成されています (外部から:インフラストラクチャ、インターフェイス、ユースケース、およびドメイン)。原則の 1 つは依存関係の規則です。ソース コードの依存関係は内側のみを指すことができます。

私のUserタイプはドメイン層の一部であるため、IDタイプは のために選択されたデータベースに依存することはできませんUserRepository。MongoDB を使用している場合、ID はObjectId( string) である可能性がありますが、PostgreSQL では整数を使用する可能性があります。ドメイン層のUser型は、実装する型が何であるかを知ることができません。

依存性注入により、実際の型 (例: ) がインターフェイスMongoUserRepositoryを実装し、メソッドを提供します。これはインターフェイスまたはインフラストラクチャ層で定義されるため、(より内側の) ドメイン層での定義に依存する可能性があります。UserRepositoryFindByIDMongoUserRepositoryUserRepository

使用を検討しました

ただし、外側の層のいずれかのコードが誤った実装型を割り当てようとすると、コンパイラはあまり役に立ちません。

データベースが指定されているインターフェイス レイヤーまたはインフラストラクチャ レイヤーで特定のタイプを決定して要求したいのですUserIDが、ドメイン レイヤー コードにその情報をインポートさせることはできません。依存関係の規則に違反するからです。

私も検討しました（そして現在使用しています）

ただし、これは、データベースが ID に文字列を使用するという知識を前提としています (私は MongoDB をObjectId-- の型シノニムで使用していますstring)。

コンパイラが最大限の型安全性を提供し、依存関係の規則に違反しないようにしながら、慣用的な方法でこの問題を処理するにはどうすればよいですか?

Firebase クラウド メッセージングを使用しているアプリを開発しています。そして、私はクリーンなアーキテクチャを使用しています。FirebaseMessaging クラスはデータ層にあります。そのクラスは次のようになります。

ご覧のとおり、関数 sendNotification は、メッセージがデバイスに届いたときに通知を作成するためのものです。そして、この関数をレイヤーを介してプレゼンテーション レイヤーにプッシュし、通知を行うためのすべてのロジックを実行する必要があります。しかし、関数 sendNotification はリモート メッセージである引数を持っており、ドメイン レイヤーは Google Play サービスをサポートしていないため、ドメイン レイヤーを介してリモート メッセージをプッシュできないため、その方法がわかりません。この関数 sendNotification をプレゼンテーション層にプッシュする方法を知っている人はいますか?

クリーン アーキテクチャに従おうとするアプリがあり、キャッシュの無効化を行う必要がありますが、どのレイヤーでこれを行うべきかわかりません。

この例のために、と のOrderInteractor2 つのユース ケースがあるgetOrderHistory()としsendOrder(Order)ます。

最初の使用例は を使用してOrderHistoryRepositoryおり、2 番目の使用例は を使用していOrderSenderRepositoryます。これらのリポジトリは、複数の実装 (MockOrderHistoryRepositoryおよびInternetOrderHistoryRepository最初の実装) とのインターフェイスです。OrderInteractor実際の実装を隠すために、インターフェイスを介してこれらのリポジトリとのみ対話します。

Mockバージョンは非常にダミーですが、履歴リポジトリのバージョンInternetは、パフォーマンスを向上させるために一部のデータをキャッシュに保持しています。

今、私は次のことを実装したいと考えています: 注文が正常に送信されたら、履歴のキャッシュを無効にしたいのですが、実際のキャッシュの無効化をどこで実行する必要があるのか​​ わかりません。

invalidateCache()私の最初の推測は、 に aを追加し、このメソッドをインタラクター内のメソッドOrderHistoryRepositoryの最後で使用することです。sendOrder()ではInternetOrderHistoryRepository、キャッシュの無効化を実装するだけで十分です。しかし、私は実際にメソッドを内部に実装することを余儀なくされ、MockOrderHistoryRepository一部のキャッシュ管理がリポジトリによって実行されているという事実を外部に公開しています。のバージョンのOrderInteractor実装詳細なので、このキャッシュ管理は意識しなくていいと思います。InternetOrderHistoryRepository

私の2番目の推測はInternetOrderSenderRepository、注文が正常に送信されたことを知っているときに内部でキャッシュの無効化を実行することですInternetOrderHistoryRepositoryが、キャッシュ管理のためにこのリポジトリで使用されるキャッシュキーを取得するために、このリポジトリに を強制的に認識させます。OrderSenderRepositoryそして、私は私のものとの依存関係を持ちたくありませんOrderHistoryRepository。

最後に、私の 3 番目の推測は、リポジトリがモックされたときに使用される実装と、リポジトリが使用されているときの実装を備えた、ある種のCacheInvalidator(名前が何であれ) インターフェースを持つことです。これは に注入され、選択された実装は、リポジトリを構築している とによって提供されます。これは、 と を構築している - と と を構築している - を持つことを意味します。しかし、ここでも、これを の最後に使用するか、直接使用するかはわかりません。DummyRealInteractorInternetCacheInvalidatorInteractorFactoryCacheInvalidatorMockedOrderHistoryRepositoryFactoryMockedOrderHistoryRepositoryDummyCacheInvalidatorInternetOrderHistoryRepositoryFactoryInternetOrderHistoryRepositoryRealCacheInvalidatorCacheInvalidatorInteractorsendOrder()InternetOrderSenderRepository(インタラクターは内部にキャッシュ管理があることをおそらく知らないはずなので、後者の方が優れていると思いますが)。

これを構築するためのあなたの好みの方法は何ですか?

どうもありがとうございました。ピエール

私は Android のクリーン アーキテクチャを学習中です。これを例として使用しています https://github.com/dmilicic/Android-Clean-Boilerplate

コードをよりよく理解するために、いくつかのコードのクラス図を作成しましたが、これは私を襲いました。アーキテクチャの使用方法に関する著者の説明を使用すると、Interactor インターフェイスは「二重」に実装されます。彼は、作成されたすべてのインタラクターは、AbstractInteractor を拡張する必要があり、別のインターフェイスも実装する必要があると述べています (この場合は、Interactor インターフェイスも拡張している WelcomingInteractor.

これは作者側の単なるミスでしょうか。またはこれには正当な理由がありますか？

よろしくモーテン