clean todo
1.0.0
メディアに関する記事へのリンク
概念と実装の詳細については、記事をご覧ください。
Clean Architectureは、伝説的なRobert C. Martin（別名「Aundle Bob」）の実用的なソフトウェアアーキテクチャソリューションです。ソフトウェアの普遍的なルールを適用することにより、あらゆるソフトウェアシステムの生涯を通じて開発者の生産性を劇的に向上させることができます。
なぜ行われていない決定の数を最大化するのですか？!!開発者として、プロジェクトの開始時に選択するフレームワーク（データベースやWebフレームワークなど）がプロジェクトの存続期間中に置き換えるのは難しいことであり、それは緊密な結合と他の多くの初期の決定のために、これらのフレームワークに基づいてプロジェクトを構築し、ビジネスロジックを導くことができることを知っています。答えは、変化を可能にするアーキテクチャを構築する必要があるということです。はい、私は変化を強調します。コアロジックと高レベルのコンポーネントを押すことなく、低コンポーネントとフレームワークの変更。
このパターンは、すべてのソフトウェアプロジェクトは、ポリシーと詳細という2つの要素のみで構成されていることを強調しています。ポリシー（高レベルコンポーネント）は、すべてのビジネスルール、すべてのエンティティ、およびそのソフトウェアに対して独自のアイデンティティを作成するすべてのものを含むソフトウェアシステムのコアです。 eコマースプラットフォームでの顧客エンティティやチェックアウトアクションのように。詳細（低レベルのコンポーネント）は、人間がビジネスルールと相互作用できる方法であり、パターンはこれらをIOデバイス、データベース、Webサーバーなどと名付けます。対応するビジネスルールをトリガーするチェックアウトボタンのように、またはその顧客エンティティがデータベースまたはファイル、または持続メカニズムを維持します。
パターンの最終目標は、高レベルのコンポーネントを低レベルコンポーネントから分離し、それらを協力して詳細の変化から高レベルの免疫を維持しようとすることです。いくつかの例で、このアイデア全体をあなたの心に具体的にしましょう。 MySQLのようなリレーショナルデータベースの上に構築され、Express JSをWebサーバーとして使用するソフトウェアを想像してください。1年後、利害関係者はリレーショナルデータベースと矛盾し、NOSQLデータベースを必要とする新しい要件と機能を導入します。ソフトウェアの実装がコンポーネント間のゆるい結合を備えた優れたアーキテクチャに従う場合、変更とともに革命を行う必要はありません。データベースまたはWebサーバー、またはビジネスルールや高レベルのコンポーネントに影響を与えることなくソリューションに適合するソフトウェアのその他の詳細を交換するのは非常に簡単です。
ボブおじさんは、きれいなアーキテクチャパターンに組み込まれた堅実な原則を強調して、読みやすく、保守可能で、スケーラブルで簡単な展開可能なソフトウェアソリューションを形成します。
