「重大な変更」を防ぐためのアーキテクチャ/アプリケーションの実践
お客様が機能の広い領域について気が変わったアプリケーションがあり、この領域は大量の再作業を必要とします。
再作業自体は問題ではありませんが、変更の影響が次のように広範囲に及ぶ状況が発生しています。
- データ
- クエリロジック/テーブル構造
- ビジネスの論理
- ディスプレイ/プレゼンテーション
理想的には、これらの変更を他のいくつかの開発ストリームと同時に組み込むことを望んでいますが、変更の影響が、提供できる頻度に悪影響を与えるのではないかと心配しています。ブランチを介してこれらの一部に対応することはできますが、アプリケーションアーキテクチャまたは開発プラクティスの観点から、この種のことを防ぐための可能性は何かと思いました。
現在行っていること：
- クエリロジックをリポジトリに抽象化する-これは小さな変更には最適ですが、エリア内の全体的なロジックが変更された場合（例：特定の条件を満たすユーザーのリストを取得する代わりに、場所に参加している組織のリストを取得する必要があります。
- ビジネスロジックをサービスに抽象化する-これは、ロジックシフト全体を実際に防ぐことができないという点でリポジトリとまったく同じですが、小さな変更は限られた影響で対応できます。
- 再デプロイ、データベース行またはweb.config値の組み合わせを必要とするコードから構成が除外されていることを確認します。
- 必要に応じて工場などの柔軟性の側面を促進する他のパターン。
- 2つのアプローチが最初に開発された場合、機能を選択するための機能フラグ。等
ブランチなどを組み込むことなく、変更を防ぐための現在のベストプラクティスは他にありますか？
変更の影響を減らすためにできる唯一のことは、プロジェクト全体を多くのコンポーネントに分割することです。したがって、大きな変更はそれらのいくつかに影響を与えますが、多くは影響を受けません。
たとえば、顧客が、中間層を介してデータを送信してDBの新しい列に格納する新しいボタンが必要であると判断した場合、システムのすべてのレイヤーを変更する必要があります。ただし、システムも「水平方向」に分割されている場合、UIの影響はUIレイヤーの一部にのみ影響し、残りは変更されません。同様に、中間層に多くのサービスがあり、それぞれがデータの特定の部分を処理する場合、そのうちの1つを変更するだけで済み、残りは影響を受けません。 DBも、独立したスキーマに分割できます。
たとえば、ユーザーのリストを取得する必要があるため、ユーザーデータを管理するサービスがあります。組織のリストも取得する必要がある場合は、これを処理する新しいサービスを追加し、UIでデータをマージします（たとえば）。つまり、ユーザーアクセスコードをまったく変更する必要はありません。この種のアプローチは microservices と呼ばれていると思いますが、明らかに「micro」は小さな意味である必要はなく、論理的に分離されているだけです。
抽象化を導入しようとはしません。これは、レイヤーを結び付けるだけだからです（たとえば、DBの変更には、基になるテーブルの変更が必要ですが、ラッピングDALレイヤーも変更する必要があり、DALがあるとは限りません。より複雑にならない限り、DBをセクションに分割できます）。