Reactを使用したドメイン駆動型のデザイン

Reactの世界でフロントエンドアプリケーションを整理する方法に関するガイダンスはほとんどありません。 （「正しいと感じる」までファイルを移動するだけです笑）。真実は、私たちがより良くできるということです。サイトをアーキテクチャ化するために使用することを検討できるパターンを1つ見てみましょう。

最初は、コードを /コンポーネントと /コンテナフォルダー間で分割する場合があります。これは小さなサイトで機能しますが、より大きなサイトにスケーリングするときに、より堅牢なものを探していることがわかります。幸いなことに、システム設計に関する数十年にわたる研究により、スケーラブルなアーキテクチャを作成するために探索する豊富なパターンが得られました。

それらの1つはドメイン駆動型のデザインであり、ここ数年で人気を取り戻しました。 React-Landで使用する方法を探りましょう。

ドメイン駆動型デザインのプライマー

ドメイン駆動型設計（DDD）は、基礎となるデータモデルをドメインロジックに関連付けることにより、ソフトウェアアプリケーションの複雑さを管理する慣行です。それは口いっぱいですので、さらに分解しましょう。

ドメインはオントロジーであり、物事が世界でどのようにグループ化されるかを意味します。たとえば、 Joistという言葉には、建物構造のドメインに非常に具体的な接続があります。マイクのような別の言葉は、聖書の名前の領域（マイケルの略）や、NATOの音声アルファベットに関連する政治の領域など、複数のドメインに属することができます。

デザインがドメイン駆動型である場合、複雑さを管理するためにコンテキスト（ゲームなどのコンテキストグループ化など）にドメインのモデル（ポーカーのドメインのトランプ）を配置することを意味します。

DDDサイトの整理

ドメイン駆動型の設計は、成長サイトの複雑さをより多くのモデルを追加するため、特に特別に処理するためのものです。 1つのモデルを備えたサイトにとっては意味がありません。約4つのモデルに到達したら、モデルを複数のコンテキストにバインドすることを検討し始めるのに良い時期です。これは難しいルールではないので、複数のコンテキストに侵入する必要があるとは感じないでください。ただし、4つのモデルを超えると、これらのコンテキストグループが浮上し始めます。

ドメインを整理することから始めます

Twitterをサンプルサイトとして使用して整理しましょう。 Twitter内のドメインを分離する1つの方法は、ツイートを強化するブログプラットフォームと、マイクロブログが広がり、繁栄することを可能にする相互作用要素にモデルを分割することです。

これは、Twitterで懸念を分離する唯一の方法ですか？間違いなくそうではありません！ DDDの重要な側面の1つは、ドメインを作成する正しい方法がないことです。アプリケーションの境界のあるコンテキストを分割する方法はたくさんあるので、選択したアーキテクチャにあまり集中しないでください。代わりに、これをスプリングボードとして使用して、DDDをフロントエンドコードの組織に適用する方法を理解します。

とはいえ、私たちのコードは、このように見えるように構造化されます（Create-React-Appのようなものから始めると仮定します）：

 Twitter/
├├。css
├├。Js
├） app.test.js
├├）/ブログ/
└└）/相互作用/

各ドメインのコンポーネントとコンテナを定義します

基本的なフォルダー構造がセットアップされたので、実際のコンポーネントを追加する時が来ました！上記のドメインUML図を見ると、特定のページにデータを取得するコンテナと、それらのページを構成するテンプレートを整理するコンポーネントから始めると便利です。アプリで拡張すると、次の構造が整っています（添付のtest.jsファイルを簡単にするために省略します）：

 Twitter/
├├。css
├├。Js
├） app.test.js
├├）/ブログ/
homepage.js
││。。
│├。。
│├│。-TweetList.js
│├│。。TweetListitem.js
│││。-userpage.js
│└│。-usercard.js
└└）/相互作用/
    pollowbutton.js
    ├·ックス。Button.jsのように
    └）sharebutton.js

ルートレベルのHTMLタグに対するReactを初期化するために、アプリファイルを保持しています。ドメインを配置すると、コンテナ（ホームページやユーザーページなど）とコンポーネント（TweetCardやTweetListitemなど）の構築を開始します。または、ドメイン内のモデルをさらにセグメント化して、次のようにすることもできます。

 Twitter/
└└）/ブログ/
    ├├）-ユーザー/
    homepage.js
    │├│。-usercard.js
    │││。-userpage.js
    └└）/ツイート/
        weetcard.js
        ├··ックスtweetdialog.js
        ├）tweetlist.js
        └└。。TweetListitem.js

しかし、アプリケーションのサイズを考えると、この段階では必要ありません。

必要に応じてヘルパーを追加します

アプリケーションを構築するにつれて、UIは複雑さが増加し続けます。これに対処するために、懸念を分離し、コンポーネントテンプレートからロジックを引き出すための2つの方法があります。プレゼンターとユーティリティです。プレゼンターは、すべての視覚的なプレゼンテーションロジックをテンプレートから押し出して、ビューレイヤーを可能な限りクリーンでシンプルに保ちます。ユーティリティは、テンプレートに特に関連していないフロントエンドの他のすべてのロジックの共有機能を収集します。これらをもう少し詳しく調べましょう。

プレゼンターと一緒にテンプレートをクリーンアップします

Twitterプロフィールを考えてください。私のアカウントでここでどのような要素を見ていますか？

ユーザーに直接関連する情報があります：名前、ハンドル、説明、場所、ウェブサイト、誕生日、開始日。他のモデル間には関連性のカウントもあります。他の何人のユーザーが私をフォローしていますか？他に何人のユーザーをフォローしていますか？私のツイート、返信、メディアのアップロード、私が気に入ったコンテンツなど、ページにさえキャプチャされていない追加のロジックがあります。このすべてのプレゼンテーションロジックを適切にキャプチャするために、ファイルツリー内に追加ファイルを追加して、JSXコンポーネントからプレゼンターパターンを分離できます。

 Twitter/
└└）/ブログ/
    ├├）-ユーザー/
    │├│。-usercard.js
    │├クアード。presenter.js

ロジックをユーティリティに押し出します

特定のプレゼンテーションロジックは非常に基本的であるため、レンダリング内で使用されているかどうかに関係なく、アプリケーション全体で役立ちます。通貨のフォーマット、検証、およびタイムスタンプのフォーマットはすべて、アプリケーション全体で孤立したユーティリティ機能から利益を得ることができるユースケースです。それらはどこに住んでいますか？ドメインに及ぶため、ユーティリティは独自のフォルダーになります。

 Twitter/
    ├├。css
    ├├。Js
    ├） app.test.js
    ├├）/ブログ/
    homepage.js
    ││。。
    │├。。
    │├│。-TweetList.js
    │├│。。TweetListitem.js
    │├│。-usercard.js
    │││。-usercard.presenterjs
    │││。-userpage.js
    ├├）/相互作用/
    pollowbutton.js
    │├│。-button.js
    │└│。-sharebutton.js
    p
         ├├。Currency.js
         ├··ックスtime.js
         └└）

アプリを整理するための間違った方法はありません！

最終的に、選択はあなたのものです。これは、アプリケーションを手配できる無数の方法のほんの一例です。ドメイン駆動型の設計は、ビジネスロジックを意味のある方法で分離し、開発者間のドメインの専門知識に明確な区別を作成し、コードを簡単に整理してスケーリングするためのルールを提供するため、貴重なツールです。

ただし、Reactアプリケーションファイル構造の従来のカオスの代替品を探している場合は、ドメイン駆動型のデザインを見てください。それはただのことかもしれません。

最後に、この種のコンテンツが好きで、フロントエンド、ユーザーインターフェイスの開発、UXの設計と研究（業界での経験によって編成）について詳しく知りたい場合は、チェックアウトしたい無料のニュースレターを実行します。

以上がReactを使用したドメイン駆動型のデザインの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。