architecture - 建築上の難問

Question

1 人でプロジェクトに取り組んでいるときの最悪の事態は、通常、同僚から得られる情報が不足していることです。そして、それが欠けているために、明らかな間違いを犯す傾向があります。

しばらくその道を進んだ後、コミュニティからの助けが必要になります。

私は、ある種のポータルになる小さな自作プロジェクトを開始しました。そして、私を悩ませている主なものは、私が作成した永続層です。手始めにプレゼンテーション層から完全に分離する必要があり、OR マッパーもどこかにあります。これは、使用する必要があるデータ ストアが複数あるためです。

したがって、基本的な考え方は、個々の「リポジトリ」が個々のデータベースでそれぞれ動作し、ビジネス層がビジネス オブジェクトを集約し、プレゼンテーション層でビュー オブジェクトに変換するというものでした。

私が直面する主な問題は次のとおりです。

同じ概念に対する複数のクラス- ユーザーの DAL 表現とユーザーの BL 表現、およびユーザーのビュー表現があります。ツールで変換を処理できますが、これは本当に正しい方法ですか。つまり、それらはすべてうまく分離されていますが、オーバーヘッドはかなりのものです。

どう思いますか？懸念の分離のうさぎの穴に深く入り込みすぎているのでしょうか、それともこれはまだ正常ですか?

Answer 1

率直に言って、これに問題はありません。別々のレイヤーのデータに対して別々のクラスを持つということは、他のレイヤーを変更せずに 1 つを変更できることを意味します。通常、他の表現の追加コストはごくわずかです。通常、タイピング速度は生産性の要因ではありません。

OTOH、スタック全体を変更する義務を負わずにデータストレージに関する何かを変更できると、多くの場合、同じ構造を複数の目的で使用すると、変更を行うときに予期しない副作用が発生するため、時間と労力を大幅に節約できます。

IOW、複数のレイヤーを介して変更を伝播する必要がある場合は最悪の場合がありますが、多くの場合、適切なツールなどによって支援できます。一方、データレイヤーの些細な変更が UI に予期しない副作用をもたらす場合、それは常に最悪です。 、何をしてもシステム全体の何かが壊れる可能性があるため、変更が遅くなります。

Answer 2

これは通常以上です。
通常、これを行う人は誰もおらず、html などをレンダリングするときの ORM の遅延読み込みの問題について叫びます。

DA、BLL、UI を同時に考えるよりも、DTO レイヤーを作成する方が簡単です。さらに進んで、アーキテクチャ スケールでコマンドとクエリの分離を適用し、入力と出力の間に明確な境界線を引くものもあります (これにより、実際にはレポート目的でのみ使用される人工的なビジネス オブジェクトの必要性などの問題が解決されます)。

---

一方、場合によって異なります。アプリをシンプルにする場合は、それほど抽象化する必要はないかもしれません (単純な会社のポートフォリオのホームページなど)。

Answer 3

これは、複数のリポジトリを持つ危険性です。これにより、「それらすべてが必要かどうか」という差し迫った問題が発生します。それらのいずれかを統合することは理にかなっていますか?

データ アーキテクチャについて読むことをお勧めします。私自身はまったくの初心者ですが、非常に経験豊富な人から素晴らしい情報を得ることができました。1 つの見解は、データ アーキテクトは、物理データベースが実際にどのように組み立てられるかよりも、データがどのように定義されるかについてより心配しているということです。私のアドバイスは、論理データ モデルと物理データ モデルをキャプチャして文書化 (モデリング) することから始めることです。データを本当に明確に理解することは、非常に役立ちます。

これの詳細 (つまり、DA が心配しているビット) は、データの定義です。このデータのビットは何ですか (列とテーブルの名前に依存しないでください)。それはどのように使われ、何を意味し、どこで作られますか? また、重要なのは、システム内で物理的に作成された場所についてではなく、ビジネス プロセス内で作成された場所について話していることです。はい、システムについて心配する必要がありますが、それは後で説明します。ビジネスプロセスがシステムを駆動する必要があります。これらはすべて論理データモデルのものです。

定義ができたら、それをつなぎ合わせることができます - 異なるリポジトリからのデータはどのように関連していますか? （おそらく、ここでは物理モデルにもっと入ります）。

すべてが明確になったら、アプリにどのように組み合わせるかについての答えが明らかになり始めるはずであり、それを文書化することが役立ちます. これは、優れたドキュメントを持つことが実際に不可欠な例の 1 つです。