クリーンなアーキテクチャの簡単な紹介

私が貢献し始めたオープンソースプロジェクトでは、「クリーンなアーキテクチャ」の概念がもたらされました。

最初はかなり圧倒的でしたが、少し読んだ後は理にかなっています。自分の考えを書き留めておけば、他の人にも役立つのではないかと思いました。

目次

  • 視覚的表現
  • コンセプト—箇条書きで示されています
  • コード例
  • リソース

視覚的表現

視覚化から始めるのは常に良いことだと思います。

これがこの概念の最も一般的な写真です。

コンセプト—箇条書きで示されています

ソースとクレジットから拡張:Mattia Battiston、CC BY 4.0

それが提供できる価値

  • テストピラミッドに続く効果的なテスト戦略
  • フレームワークは個々のモジュールに分離されています。私たちが考えを変えるとき(そうでない場合)、私たちは一箇所で変更を加えるだけで済みます。アプリには、CRUDシステムに縛られるのではなく、ユースケースがあります
  • 悲鳴を上げるアーキテクチャ、別名それは意図された使用法を悲鳴を上げます。パッケージの構造を見ると、技術的な詳細を見るのではなく、アプリケーションが何をしているのかを感じることができます。
  • すべてのビジネスロジックはユースケースに含まれているため、簡単に見つけることができ、他の場所に複製されることはありません。
  • モジュールはコンパイルの依存関係を強制するため、間違ったことをするのは難しいです。意図しないものを使おうとすると、アプリがコンパイルされません
  • オブジェクトの配線を最後まで残すことで、いつでもデプロイする準備ができています。または、フィーチャーフラグを使用することで、継続的インテグレーションのすべてのメリットを享受できます
  • 複数のストーリーで作業するため、異なるペアが同じストーリーで同時に簡単に作業して、ストーリーをすばやく完成させることができます
  • マイクロサービスについて詳しく学んだら、後でマイクロサービスに分割できる明確なユースケースを備えた優れたモノリス

エンティティ

  • ドメインオブジェクトを表す
  • エンティティ全体に一般的に適用できるロジックのみを適用します(たとえば、ホスト名の形式の検証)
  • プレーンオブジェクト:フレームワークなし、注釈なし

ユースケース

  • あなたのビジネスアクションを表現してください:それはあなたがアプリケーションでできることです。ビジネスアクションごとに1つのユースケースを期待する
  • 純粋なビジネスロジック、プレーンコード(一部のutilsライブラリを除く)
  • ユースケースは、誰がそれをトリガーし、結果がどのように表示されるかを知りません(たとえば、Webページに表示されるか、JSONとして返されるか、単にログに記録されるなど)。
  • ビジネス例外をスローします

インターフェース/アダプター

  • 多数のソース(データベース、ネットワークデバイス、ファイルシステム、サードパーティなど)との間でデータを取得および保存します。
  • いくつかのロジックを適用するために必要なデータのインターフェースを定義します。1つ以上のデータプロバイダーがインターフェイスを実装しますが、ユースケースはデータがどこから来ているのかわかりません
  • ユースケースで定義されたインターフェースを実装する
  • アプリケーションと対話する方法はいくつかあり、通常は配信メカニズム(REST API、スケジュールされたジョブ、GUI、その他のシステムなど)が関係します。
  • ユースケースをトリガーし、結果を配信メカニズムに適した形式に変換します
  • MVCのコントローラー

外部インターフェース

  • 最も適切なフレームワークを使用してください(とにかくここで分離されます)

コード例

GitHubの構造を参照してください。

まず第一に、クリーンなアーキテクチャは組織化の原則の束であることを理解することが重要です。したがって、コアアイデアが損なわれない限り、すべてが個人的な調整に開かれています。リンクされたリポジトリは、このアーキテクチャ設計のアイデアを私にもたらした元のプロジェクトのフォークです。さらなる改善が反映されているので、元のプロジェクトも自由にチェックしてください。

webminerフォルダーは、基本的なレイヤーで構成されています。

  1. エンティティ
  2. use_cases
  3. interfaces_adapters
  4. external_interfaces

これは、デザインパターンの非常に基本的なアプローチを反映するものとします。

  • から始めてentities、このプロジェクトのコアモデルはarxiv_document
  • 次のフォルダーはuse_cases、arxivページをリクエストするユースケースを示しています
  • その後interface_adapters、RESTアプリケーションでのプロセス要求またはシリアル化用のアダプターを提供するフォルダーを調べます。
  • 最後の最後のレイヤーはexternal_interfacesです。ここで、フラスコサーバーを使用してREST機能を実装します

これらのレイヤーはすべてコアレイヤーに依存していますが、その逆はありません。

重要な注意事項:これは、リポジトリに100%正しく実装されているわけではありません。

どうして?ユースケースが実際には異なるためです。実際には、主なユースケースは構造化データを提供することです。別のユースケースは、arxivページからデータを取得することです。

アーキテクチャでこのエラーを見つけましたか?はいの場合、おめでとうございます!この記事に十分な好奇心を持っただけでなく、独自のケースを構築して実際に概念を適用するのに十分な原則を理解している可能性があります。

同意しますか?そうでない場合、なぜですか?私の記事を読んでくれてありがとう!フィードバックはお気軽にどうぞ!

リソース

「クリーンアーキテクチャ」の概念を理解するのに役立つと思った記事を次に示します。

  • //8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
  • //www.codingblocks.net/podcast/clean-architecture-make-your-architecture-scream/
  • //github.com/mattia-battiston/clean-architecture-example
  • //medium.com/@tiagoflores_23976/how-choose-the-appropriate-ios-architecture-mvc-mvp-mvvm-viper-or-clean-architecture-2d1e9b87d48
  • //de.slideshare.net/HimanshuDudhat1/mvp-clean-architecture
  • //softwareengineering.stackexchange.com/questions/336677/what-is-the-difference-between-mvp-and-clean-architecture
  • //engineering.21buttons.com/clean-architecture-in-django-d326a4ab86a9
  • //gist.github.com/ygrenzinger/14812a56b9221c9feca0b3621518635b
  • //medium.freecodecamp.org/how-to-write-robust-apps-consistently-with-the-clean-architecture-9bdca93e17b
  • //marconijr.com/posts/clean-architecture-practice/

ダニエルはLL.Mです。ウィーンでソフトウェアエンジニアおよび技術関連イベントの主催者として働いている、商法の学生。彼の現在の個人的な学習努力は、機械学習に焦点を合わせています。

接続:

  • LinkedIn
  • Github
  • ツイッター
  • Steemit
  • ハッシュノード