関心の分離はドメインとプレゼンテーションから考える(PDS)
PDS = Presentation Domain Separation
Why
原則
ユーザーに触れる部分であるため変化が早く、安定度も低い
局所最適化が求められ再利用の高い処理は少ない
テストしにくい
UIをテスタブルに作るための実装は冗長になり、ROIが悪い 対してドメインは
プレゼンテーションとは違った部分の頭を使う
ドメインとプレゼンテーションの結合度を下げねばならない 末端の見た目の処理こそ優先的に分離するべし
ドメインとUIを分離することによりそれぞれの責務に集中できる
他、参考
最も有用な設計原則に、 プログラム（ユーザーインターフェイス）のプレゼンテーション層とその他の機能をうまく分ける、というのがあります。 私はこれを発見して以来、ずっと慣行しています。 長い間これを使ってきて、いくつものメリットを発見しました。 - 同じ基本プログラムを、重複コードなしに、複数のプレゼンテーションに対応させることができる
- ユーザーインターフェイスはテストがしにくいため、それを分離することにより、テスト可能なロジック部分に集中できる - スクリプト用のAPIやサービスとして外部化するためのAPIを楽に追加できる（選択可能なプレゼンテーション部分で見かける） - プレゼンテーション部分のコードは、ドメイン部分のコードと違ったスキルと知識が必要 これら多くのメリットがあるにも関わらず、この原則が破られているのをよく目にします。知識が無いという理由もあるでしょう。フレームワークが、ドメインとプレゼンテーションを安易にごちゃまぜにしてしまい、分割が困難になっているという理由もあるでしょう。 すべてのコードが同じマシンで動いているとしても、論理的には分割したほうがよいのです。
ドメイン部分のコードと Web Services 部分のコードをごちゃまぜにしてはいけないのです。外部APIにしてもそうです。
Building React application, or a frontend application with React as its view, should not be treated as a new type of software. Most of the patterns and principles for building the traditional user interface still apply. Even the patterns for constructing a headless service in the backend are also valid in the frontend field. We can use layers in the frontend and have the user interface as thin as possible, sink the logic into a supporting model layer, and data access into another.
---
Reactアプリケーション、あるいはReactをビューとするフロントエンド・アプリケーションの構築は、新しいタイプのソフトウェアとして扱うべきではない。従来のユーザーインターフェイスを構築するためのパターンや原則のほとんどは、今でも適用できる。バックエンドでヘッドレス・サービスを構築するためのパターンさえ、フロントエンドの分野でも有効だ。フロントエンドでレイヤーを使い、ユーザーインターフェイスを可能な限り薄くし、ロジックをサポートするモデルレイヤーにシンクし、データアクセスを別のレイヤーにすることができる。
これは新しいことではなく、サーバー等においてプレゼンテーションとそれ以外とを分ける、という基本に忠実になるということ
プレゼンテーション系で何が行われているかをリポジトリは何も知らないし、プレゼンテーション系は “UI Store” までしか意識せずに済む。
https://scrapbox.io/files/641101e9abb05d001c3ea1e7.png
https://scrapbox.io/files/641101fcb1f6b3001b44447f.png
https://scrapbox.io/files/64110259727435001b0bd511.png