息子のビジネスロジックはどこにありますか？

土曜日に雨が降った天国に感謝し、私はそれを読みました（そしてあなたは翻訳してくれてありがとうと言います）。 しかし、日曜日には太陽が輝いており、テキストの書式設定が遅れていました。



別の出版を許可してくれた著者に感謝します。



ビジネスロジックとは何か、それがどこにあるかについての非常に面白い記事。 ちなみに、この記事はすでに3年前のものです。 また、コードがデータから分離されていないシステムによく遭遇します。 本物のホリバーにつながる可能性があります。

息子のビジネスロジックはどこにありますか？

はじめに

長年の開発を経て、デスクトップからクライアントサーバーアーキテクチャに移行し、3リンク設計、nリンク、サービス指向に移行しました。 このプロセスの間、多くのことが変化しましたが、多くの習慣が残っていました。 多くの場合、変化に対する抵抗は習慣から生じます。 ただし、多くの場合、手続き的です。 この記事では、私たちが間違っていることと可能な解決策について説明します。

記事について

ここで説明するのは、nリンクシステムを設計とアーキテクチャの観点から構築する方法の1つです。 この記事はコードに焦点を合わせていません。 nリンクシステムを構築する方法は多数ありますが、これはそのうちの1つにすぎません。 システムを構築する場合は、このアプローチを使用するための良いアドバイス、テクニック、またはテンプレートを見つけてください。

この記事は「標準的な方法」からいくつかの出発点を提供するかもしれませんが、この記事のすべてはMicrosoftのテンプレートと方法に基づいており、 データ層コンポーネントの設計と層や他のドキュメントを介したデータの受け渡しで説明されています。



ここで提案したすべての方法論をあえて適用しない場合でも、少なくともそれらのいくつかを使用する必要があります。

目的

開発者にビジネスロジックのあるべき場所を尋ね、「もちろんビジネスレイヤーで」という答えをもらいます。

同じ開発者に、ビジネスロジックが組織のどこにあるかを尋ねて、「もちろん、ビジネスレイヤーで」と聞きます。



ビジネスロジックのどこにビジネスロジックを置くべきかについて、少しでも疑うべきではありません。 ビジネスロジックの一部ではありません-すべてのビジネスロジックはビジネスレイヤにある必要があります。 この記事を読んだ後、多くの開発者は、自分たちのシステムについて真実だと思ったことはそうではないことを理解するでしょう。

規約

これらの用語はしばしば一緒に使用されますが、この記事では、ここで説明するように使用します。

リンク（層）

リンクという用語を使用する場合、同じ機能を実行し、容量を増やすためだけにグループ化された物理サーバーまたはサーバーのグループで構成される物理リンクを意味します。

レイヤー

レイヤーという言葉を使用するとき、私はそれ自身のプロセスまたはモジュールに限定されるシステムのセグメントを意味します。 1つのリンクに多くのレイヤーを含めることができますが、いずれのレイヤーも別のリンクに簡単に転送できる必要があります。

問題開発

デスクトップ

デスクトップアプリケーションでは、ビジネスロジックは他のすべてのレイヤーと同じリンクに含まれています。 なぜなら レイヤーを分離する必要はありません。レイヤーはしばしば混合され、明確な境界はありません。

クライアントサーバー

クライアント/サーバーアプリケーションには2つのリンクがあり、少なくとも2つのレイヤーが作成されます。 初期段階では、サーバーはリモートデータベースのみと見なされ、分割は図のように行われました-クライアント上のアプリケーションとサーバー上のデータ。 通常、すべてのビジネスロジックはクライアント上にあり、ユーザーインターフェイスなどの他のレイヤーと混合されていました。







すぐに、ほとんどのビジネスロジックをサーバーに移動することにより、ネットワークの負荷を軽減し、ロジックを集中化して固定展開コストを削減できることが明らかになりました。 アーキテクチャ的には、サーバーはクライアントサーバーシステムで十分に準備された場所でしたが、プラットフォームとしてのデータベースはほとんど機会を提供しませんでした。 データベースはストレージと配信用に設計されており、そのアーキテクチャにはビジネスロジックの方向への拡張の可能性が含まれていませんでした。 データベースストアドプロシージャ言語は、基本的なデータ変換用に開発され、SQLに欠けていたものをサポートします。 ストアドプロシージャ言語は、複雑なビジネスロジックタスクを処理するためではなく、高速実行のために開発されました。



しかし、2つの悪のうち、これはより小さく、ビジネスロジックの一部はストアドプロシージャに移行しました。 実際、ビジネスロジックは縮小され、ストアドプロシージャのフレームワークに組み込まれました。これは、実用的な観点からのみです。 世界の2つのリンクでは、理想的ではありませんでしたが、それでもはるかに優れていました。

3-リンク

クライアント/サーバーアーキテクチャの問題が明らかになると、3層アプローチの人気が高まりました。 当時の最大かつ最悪の問題は、接続数でした。 現在、多くのデータベースが数千の1回限りの接続を処理できますが、90年代には、ほとんどのデータベースが約500の接続のどこかに落ちました。 サーバーは、多くの場合、クライアント接続の数によってライセンスされます。 これはすべて、データベースへの接続数を減らす必要があるという事実につながりました。



接続のプーリングが一般的になりましたが、多くの個別のクライアントを持つシステムに接続プールを実装するには、クライアントとサーバー間に3番目のリンクを実装する必要があります。 中間リンクは「中間リンク」と呼ばれていました。 ほとんどの場合、中間リンクは接続プールを管理するためだけに存在していましたが、場合によっては、開発言語（C ++、VB、Delphi、Java）がストアドプロシージャ言語よりもビジネスロジックの実装にはるかに適していたため、ビジネスロジックが中間リンクに移動し始めました。 すぐに、中間リンクがビジネスロジックに最適な場所であることが明らかになりました。



また、ミドルリンクは、クライアントを低速で接続する機会を提供しました。 通常、データベースへの直接接続には、広いチャネルと低遅延が必要です。

ビジネスロジックとは何ですか？

先に進む前に、ビジネスロジックとは何かを明確に定義しましょう。 会議や社内で話すと、ビジネスロジックとは誰もが同意しているわけではないことを恐れるようになりました。



データベースサーバーはストレージ層です。 データベースは、可能な限り最高の効率でデータを保存、取得、更新するように設計されています。 多くの場合、機能は制御システム（作成、削除、受信、更新）です。 一部のデータベースはSOUPであり、そうですが、会話はそれについてではありません。



データベースは、これらの操作を非常に迅速に処理するように設計されています。 電話番号の書式設定、最適な使用量とピーク負荷の計算、地理的位置と貨物ルートの決定などを目的として設計されていません。 ただし、このすべてとはるかに複雑なタスクは、ヘルプまたはほとんどのストアドプロシージャでのみ実装されています。

バイヤーを削除

そして、これはすべて複雑なものだけに当てはまりません。 単純なタスクと、多くの場合ビジネスロジックにも関連しないタスクを想像してみましょう。 タスクはバイヤーを削除することです。 私が見たほとんどすべてのシステムでは、顧客の削除はストアドプロシージャによってのみ処理されます。 ただし、バイヤーの削除では、ビジネスロジックのレベルでかなりの数の決定を行う必要があります。 バイヤーを削除できますか？ 前後にどのプロセスを開始する必要がありますか？ どのような注意事項に従う必要がありますか？ どのテーブルから後でレコードを削除または更新する必要がありますか？



データベースは、バイヤーが何であるかを気にするべきではなく、バイヤーを保存するために使用される要素のみを気にするべきです。 データベースは、買い手がどのテーブルを保存するべきかを判断できず、買い手に注意を払わずにテーブルを操作する必要があります。 データベースのタスクは、顧客を説明するテーブルに行を格納することです。 カスケード整合性、データ型、インデックス、空の値などの基本的な制限に加えて、データベースには、顧客がビジネスレイヤーで何をしているのかに関する機能的な知識がありません。



ストアドプロシージャがある場合は、1つのテーブルのみで操作する必要があります。 例外は、データを生成するために複数のテーブルからの選択を要求するプロシージャです。 この場合、ストアドプロシージャはビューとして機能します。 ビューとストアドプロシージャは、値を統合するために使用する必要がありますが、ビジネスレイヤーのデータをより高速かつ効率的に処理するためだけに使用する必要があります。



しかし、開発と技術の最新の進歩を誇りに思っている企業や、口に泡があるビジネスレイヤーのビジネスロジックについて悲鳴を上げている企業でさえ、データベースの短い分析ですぐに明らかになります：買い手を削除し、買いを追加し、買いをブロックし、買いを凍結しますなど など そして、バイヤーだけでなく、ビジネスロジックの他の多くのオブジェクトとも関係しています。



私はしばしばこのようなストアドプロシージャを見てきました：

sp_DeleteCustomer(x)

Select row in customer table, is Locked field

If true then throw error

Sum total of customer billing table

If balance > 0 then throw error

Delete rows in customer billing table (A detail table)

if Customer table Created field older than one year then

Insert row in survey table

Delete row in customer table









通常、ビジネスロジックの一部はビジネスレイヤーに移動します。

Business Layer (C#, etc)

Select row in customer table, is Locked field

If true then throw error.

Sum total of customer billing table

If balance > 0 then throw error.

if Customer table Created field older than one year then

Insert row in survey table

Call sp_DeleteCustomer

sp_DeleteCustomer(x)

Delete rows in customer billing table (A detail table)

Delete row in customer table









この場合、ビジネスロジックの一部が移動されましたが、すべてではありませんでした。 一部のテーブルは、ビジネスロジック層でも処理されます。 データベースには、ビジネスレイヤでどのテーブルが顧客を形成するかについて少しも考えてはいけません。 3つの操作すべてについて、ビジネスレイヤーはSQLコマンドを発行するか、3つの個別のストアドプロシージャを呼び出して、特定のsp_DeleteCustomerの機能を実装する必要があります。

すべてのビジネスロジックをビジネスレイヤーに渡すと、次のようになります。

Business Layer (C#, etc)

Select row in customer table, is Locked field

If true then throw error.

Sum total of customer billing table

If balance > 0 then throw error.

if Customer table Created field older than one year then

Insert row in survey table

Call sp_DeleteCustomer

Delete rows in customer billing table (A detail table)

Delete row in customer table









行が同じテーブルからのものである場合、行を削除するにはストアドプロシージャを使用できます。 ただし、クエリキャッシュを使用する最新のデータベースでは、これはわずかなパフォーマンスの向上です。 さらに、そのようなシステムによって生成されるSQLは非常に単純です。 1つのテーブルで機能するため、実際には最適化は必要ありません。 実際、ロードされたストアドプロシージャが多すぎると、データベースはあまりうまく機能せず、単純なSQLコマンドはそのようには機能しません。



テーブルの変更もビジネスレイヤーに転送することで、次の利点が得られます。

• データベースの移行は、次のように少ない労力で実行できます。 これらのストアドプロシージャはすべて、DBMSごとにデバッグする必要はありません。
• 変更が簡単です すべてのロジックは2つではなく1つのレイヤーに含まれています。
• デバッグは簡単です-ロジックは2つのレイヤーに分散されません。
• 「簡単だから」という理由だけで、他のロジックがストアドプロシージャに滑り込むことはありません。

この方法では、データベースへのアクセスが1回ではなく3回必要であるため、ビジネスロジックノードは、ギガビットなどの別の高速セグメントを介してデータベースに接続する必要があります。 100バイトの代わりに300バイトを送信すると、原則がなくなります。 ほとんどのデータベースはSQLクエリのバッチ転送をサポートしており、3つのクエリすべてを1つのバッチで送信できるため、ネットワークの負荷が軽減されます。 このようなリクエストを発行するには、データアクセスレイヤーを使用し、コードに直接リクエストを含めないでください。



一部のデータベース管理者や開発者でさえ、このレベルの統合を受け入れず、ストアドプロシージャにこのようなバッチ更新を実装することを要求する場合があります。 これはあなたがしなければならない選択であり、あなたのデータベースとあなたの優先度に非常に依存しています。 なぜなら ほとんどすべての最新のデータベースはクエリキャッシングメカニズムを使用しており、ほとんどの場合、パフォーマンスの向上は最小限であり、ストアドプロシージャにロジックを読み込まないことには明らかな技術的理由があります。 そのようなバッチ更新をストアドプロシージャに残すことを選択した場合、他のビジネスロジックがストアドプロシージャに滑り込まないようにし、条件付き操作や他のビジネスロジックのないLOSオペレーションにストアドプロシージャを制限しないように注意する必要があります。

書式設定

私が発見し、開発者間の戦争の種をsoいた別の例を見てみましょう-このビジネスロジックかどうか。 ユーザーインターフェイスやストレージではなく、ビジネスロジックと考える理由を説明します。 この例は、簡単に実装できるフォーマットには適用されません。 私が使用する例は電話番号です。

各国には、電話番号を快適に表示するための独自の形式があります。 一部の国では、さらに複数あります。 以下にいくつかの例を示します。



キプロス：

+357（25）66 00 34

+357（25）660 034

+357 25660 034

+357 2566 0034

ドイツ：

+49 211 123456

+49 211 1234-0

北米（米国、カナダ）

+1（423）235-2423

+ 1-423-235-2423

ロシア：

+7（812）438-46-02

+7（812）438-4602



ドイツでは、フォーマットに関する特別な公式標準であるDIN 5008もあります。



もちろん、ローカルで使用される場合、国コードは破棄されます。 しかし、国際システムがあり、国コードを保存および表示する必要があると仮定しましょう。 国ごとに、1つの表示形式を選択します。



電話を次のようにフォーマットすることに同意します。

• データにはさまざまな形式があります。
• 各国には、電話を表示する独自の方法があります。
• 一部の国の形式は単純ではなく、最初の数字によって異なります。
• 最初の数桁（通常、国コードと地域コード）は、常に固定長ではありません。 たとえば、ロシアでは、812はサンクトペテルブルクの都市コード、495はモスクワですが、一部の地域には4文字（3952）があります。 これにより、地域コードに応じて、全体の長さと形式が変更されます。
• 新しい法律の出現、新しい事業者の出現、欧州連合の統合、電話システムの更新などにより、電話の形式と長さは世界規模で頻繁に変わります。 最近、キプロスは国コードを2回変更しました。1回はシステムの更新中、もう1回は携帯電話会社の数の増加によるものです。 世界中の何百もの国で、変化は定期的に予想されます。

通常、以下が行われ、すべての非デジタル文字が削除され、数字は次のようになります。

電話番号：35725660034



国コードが分離され、番号が次のようになる場合があります。

電話国：357

PhoneLocal：25660034



簡単に思えますが、ビジネスロジックのもう1つの課題です。 すべての国で同じ長さのコードがあるわけではありません。 国コードは1〜3文字です。



多くの場合、入力処理（国コードが分離されている場合）および表示ロジックは、次のようにクライアントに実装されます。 クライアントは、これに適した従来の言語で書かれています。 問題は、クライアントが国コードの長さを判断するために膨大な量のデータを必要とし、表示形式が変更されるたびにクライアントを更新する必要があることです。



フォーマットは、ストアドプロシージャで行われる場合があります。 このアプローチの問題は、ストアドプロシージャの言語がこのタイプのロジックに適合していないことであり、実際のロジックを操作する際にバグやブレーキにつながることがよくあります。



多くの場合、電話番号は2回保存されます。 一度はインデックス作成と検索のために純粋な形式になり、もう1つは表示用にフォーマットされた形式になります。 上記の問題に加えて、冗長なレコードと更新の問題が発生します。



途方もなく一般的である特に洗練された極端なものは、それが受信された形式で保存された電話番号を持っています。 問題は明らかです。電話をすばやく見つけたり、インデックスを付けたり、並べ替えたりすることはできません。



重要なことは、これは書式設定ですが、ユーザーインターフェイスには適用されず、完全な集中化を試みるとデータベースが破壊される可能性があることです。 これは明らかにビジネスロジックです。 ビジネスレイヤーでの書式設定の実装は、データの複製を許可せず、開発言語で記述され、データ処理言語に組み込まれません。

例外

一部のバッチ更新は、ストアドプロシージャを使用して実装すると何倍も高速になります。 ほとんどの場合、単純なSQLは不要ですが、一部の種類のバッチ更新にはループが必要であり、ビジネスレイヤーに実装すると、数千のSQLコマンドが作成されます。 このようなまれなケースでは、ビジネスロジックを実装する必要がある場合でも、ストアドプロシージャを使用する必要があります。 必要な最小値のみが実装されるように特に注意を払う必要があります。



この記事ではこの問題に戻ります。

今日のシステム

クライアントサーバー

クライアント/サーバーアプリケーションでは、通常、ビジネスロジックはクライアントとサーバーの両方で利用できます。







実際の比率はアプリケーションごとに異なります。前の例では、クライアントサーバーアプリケーションについて説明しています。 ビジネスロジックの集中化を図るため、ビジネスロジックのほとんどはストアドプロシージャとビューに実装されました。 ただし、多くのビジネスルールは、単にSQLまたはストアドプロシージャに実装することはできません。また、ユーザーインターフェイスに基づいているため、クライアントでより高速に実行できます。 これらの相反する要因により、ビジネスロジックはクライアントとサーバー間で分散されます。

Nリンク

後で別の記事で説明する多くの理由で、nリンクシステムを構築する場合、状況はビジネスロジックを統合するという点でのみ悪化します。 統合の代わりに、ビジネスロジックはさらに細分化されます。



もちろん、システムごとにビジネスロジックがレイヤー間で分散される方法には違いがありますが、すべての人に共通することが1つあります。 ビジネスロジックは2つではなく3つの層に分散されています。 次に、いくつかの典型的なシナリオを紹介します。

シナリオ1

n層システムでのビジネスロジックの一般的な配布：







このような場合、ビジネスレイヤーにはビジネスルールは含まれません。 これは実際のビジネスレイヤーではなく、XMLフォーマッター（またはその他のストリーミング形式）とデータベースデータセットアダプターのみです。 接続プーリングやデータベース分離などのいくつかの利点を実現できますが、これはビジネスロジックの実際の層ではありません。 むしろ、論理層のない外部の物理層です。

シナリオ2

別の典型的なシナリオ：







通常、一部のビジネスアプリケーションルールはビジネスレイヤーに入りますが、データベース内のほとんどの部分は同じままです。



このような開発でビジネスレイヤーを再利用する場合、クライアントアプリケーションでビジネスルールを繰り返す必要があります。 これは、ビジネス層を導入するという主な目標を否定します。







また、クライアントアプリケーションには、実装したり単に無視したりせずにビジネスルールを遵守しない機会があります。 実際のビジネス層では、これは不可能です。

統合

上記のすべての代わりに、ビジネスレイヤーにすべてのビジネスルールを含める必要があります。







このような開発には、次の利点があります。

• すべてのビジネスロジックは1つの場所にあり、簡単にチェック、デバッグ、および変更できます。
• 通常の開発言語を使用して、ビジネスルールを実装できます。 このような言語は、SQLやストアドプロシージャよりも柔軟性が高く、ビジネスルールに適しています。
• データベースはストレージレイヤーになり、ビジネスロジックまたはプレゼンテーションのレイヤーに関連する制限なしに、データの効率的な受信と保存を処理できます。

上記のシナリオが目標です。 ただし、特にデータ検証のための重複は、クライアント上にある必要があります。 これらのルールは、ビジネスレイヤーでサポートされている必要があります。 さらに、一部のシステムでは、バッチ更新などの個々の大容量操作により例外が発生する可能性があるため、データベースに配置する必要があります。 したがって、より現実的なアプローチを以下に示します。 すべてのビジネスロジックはビジネスレイヤーに実装する必要があり、他のレイヤーに存在するこれらの最小限のセットは、パフォーマンスを改善するか、特定のユーザーインターフェイスコンポーネントを無効にするためだけに複製されることに注意してください。

中央ハブへの移動

滑りやすい斜面

中央ノードに切り替える場合、「ストアドプロシージャでこの部分を実装する」という手法が常にあります。 それから「それ」と「これ」。 そしてすぐに、あなたはあなたと同じ状況にいることに気付くでしょう。大きな変化はありません。



ストアドプロシージャを使用して、SQLを実行し、表現よりもストアドプロシージャを最適化するデータベースのデータセットを取得する必要があります。 ただし、ストアドプロシージャは、データの結合と発行以外には使用しないでください。 データを更新するときは、正確かつ唯一の更新を行う必要がありますが、データの解釈は一切行わないでください。



パフォーマンスを向上させるために、一部のコンポーネントをストアドプロシージャに配置する必要があるタスクがあります。 しかし、そのようなタスクは実際には非常にまれであり、ルールではなく例外であるべきです。 各例外は、開発者またはデータベース管理者の要請で実装されるだけでなく、チェックおよび承認される必要があります。

安い

鉄を買うと安くなるのは少し奇妙に聞こえます。 しかし、中間レベルのサーバーの導入により、OS以外の追加のソフトウェアは実質的に必要ありません。 また、データベースサーバーのキャパシティを増やすコストは、次の理由により重要です。

• 原則として、データベースサーバーは中間レベルのサーバーよりも上位クラスであり、より高価です。
• データベースは多くの場合、プロセッサによってライセンスされており、プロセッサの追加はライセンスの観点からすると費用のかかる手順です。 ライセンス料は、プロセッサあたり5,000〜40,000ドルの範囲です。

ロジックを中間リンクに転送するとき、データベースの負荷を大幅に削減し、容量の早すぎる増加を防ぐことができます。

より簡単に

通常、中間レベルのアップグレードは、コストに加えて、データベースのアップグレードよりも簡単です。

データベースには、単に鉄を追加するだけでどれだけ増やすことができるかという固有の制限があります。 ある時点で、分割、クラスタリング、レプリケーションなどの他のテクノロジーの使用を開始する必要があります。 しかし、これらの技術はいずれも単純ではなく、すべてハードウェアへの多大な投資、移行を必要とし、既存のシステムに大きな影響を与えます。



中間レベルのサーバーの構築ははるかに簡単です。 負荷分散メカニズムが起動するとすぐに、すべて新しいサーバーを追加するタスクになります。

トポロジー

次の図を使用して作成したステートメントを見てみましょう。 セグメントの塗りつぶしは、ダイアグラム内のリンクに対する名前の方向または重要度を示します。 クライアントから中間リンク、データベースに移動すると、単価が上昇します。 設定に応じて、プロセッサまたはサーバーを表すためにユニットという言葉を使用します。

（上から下：単価、平均帯域幅、展開の複雑さ、数量）







同じデータが相対値で指定されている場合、簡単に比較できます。







ネットワーク構成、プロセッサー能力、および各組織に固有のその他の要因に大きく依存しているため、グラフに数値を示しませんでした。 各関数は独自のユニットを使用します。 ディメンションの一般的な関係のみを示しました。 中間リンクは成長する能力があり、データベースよりもはるかに安価であることをよく示しています。

真ん中を成長させる

ビジネスロジックのほとんどがデータベースに実装されている場合、より強力なデータベースが必要になります。







ロジックを中間リンクに転送すると、データベースの負荷を大幅に削減できます。 ここに示されている数値はデモンストレーションのみを目的としており、システムごとに異なりますが、アイデアを理解するのに役立ちます。 次の図にはより多くのハードウェアがありますが、システムの総コストは少なくなり、展開が容易になります。 中間リンクを増やす方がはるかに安価で簡単です。

ボトルネック

前のグラフの1つをもう一度見てみましょう。







システムの唯一のボトルネックは何ですか？ 明確な成長制限があるリンクはどれですか？ これは間違いなくデータベースです。 すべてはデータベースに依存します。







したがって、計算を中央のリンクに移動すると、データレイヤーの境界から離れることができます。

難しさ

中間リンクに移動するにはいくつかの困難がありますが、それらのすべてが異なるプログラミングをする必要があるというわけではありません。

習慣

「古い習慣を取り除くのは難しい」という格言があります。 これはチームにも当てはまります。 チームとして、あなたは自分自身だけでなく、チームのほとんどを納得させる必要があります。

手続き

多くの企業では、データベースのセキュリティを必要とする確立されたセキュリティポリシーを使用しており、ビューとしてストアドプロシージャを使用しても十分な制御が提供されません。企業のセキュリティポリシーを変更してn層の世界に移行することは、不可能ではないにしても、非常に困難です。

.Netでは、新しいマイクロソフトテクノロジと同様に、セキュリティはこれまでにない中レベルの企業セキュリティに焦点を当てていますが、多くの企業は依然としてデータベースに依存しており、変更を気にしないか、変更したくないと考えています。

データベース管理者

これは危険な声明です。とても危険なので、他に言いたいことがあります。あなたがデータベース管理者または開発者である場合、私が言いたいことをステレオタイプまたはすべてのデータベース管理者についての真実と受け取らないでください。ただし、これは一般的です。あなたがこの説明に該当しないDBAである場合-ブラボー！あなたはデータベースの社長ではなく、データベースの社長です。



実行中のシステムを持つデータベース管理者は、システムを壊す可能性があるため、多くの場合、大きな変更を加えることに抵抗します。多くの組織には、1人の管理者と多くのアシスタントがいます。データベース管理者は、彼の遺産の王であり、データベースに関連するすべての最後の言葉を持っています。そして、管理者のみが管理者をより良くしようとするので、すぐにデータベースの問題に対処できない管理者は管理者に委ねられます。



多くのDBAは、n層アーキテクチャの方向に変更が必要な理由についてほとんど知識を持っていないか、気にしません。彼らにとっては、どのリンクも別のクライアントであり、すべてはクライアントサーバーアーキテクチャです。彼らはデータベースについてだけ気にし、それが彼らに問題を引き起こさない場合にのみ、開発者との取引に行きます。



データベース管理者は、開発者ほど頻繁に企業に移行することはなく、その多くは過去10年または20年にわたって企業データベースを管理してきました。データベースは彼らにとって非常に重要なものであり、彼らはトランザクションを行いたくないのです。彼らは自分たちの王国を築き、コントロールを失いたくありません。そのような管理者にセキュリティと実装の一部を強制的に戻すことは、深刻な戦いと管理者の支援が必要です。



他の管理者はそれほど要求が厳しくなく、彼らが合理的であると考えるすべてを満たすようになります。しかし、多くの組織、特に大規模な組織では、数百人の開発者と1〜2人のデータベース管理者のみが存在し、データベース管理者は企業のコマンドチェーンの最上位にいます。

ツールキット

現在利用可能なツールのほとんどは不安定であるか、ビジネスロジックを実装するためのツールを提供していません。多くのツールは、スケーラビリティ、接続プーリング、およびデータベース分離にのみ焦点を当てており、ビジネスロジックのニーズを満たすことを目的としていません。

解決策

建築

システムアーキテクチャの定期的な監査では、ビジネスロジックの不適切な配置が指摘されているため、大きな利点があります。それらが発見されるのが早ければ早いほど、それらを修正するのは簡単で安価です。特別なチーフアーキテクトがいない場合、チームの開発者は互いに確認できます。間違った場所で何かが見つかった場合、開発者はチームとチームリーダーに通知できます。

アシスタントトレーニング

データベース管理者のアシスタントを訓練することは非常に便利です。管理者はビジネスロジックを長い間実装してきたため、ビジネスロジックがどこにあり、ストレージがどこにあるかを判断するのは困難です。アシスタントは通常、管理者の指示に従って、原則として必要なことだけを行います。



とにかく、プロセスはアシスタントに影響します。クエリを作成し、最適化し、データベースを維持します。また、中間リンクから送信されるSQLとデータベースのパフォーマンスも監視する必要があります。アシスタントは、データベースアーキテクチャの設計も継続します。

マネージャー研修

多くの場合、管理の抵抗に直面しますが、これは複雑な障害よりも単純な障害の可能性が高いです。経営陣は、あなたの作業が容易になったかどうかを気にしませんが、間接費、開発時間、ビジネス上の利点を気にします。



変更管理の主な障害は、データベース管理者の抵抗です。そのため、管理者を管理者に引き渡し、管理者自身に対処させます。

他に読むもの

この記事の基礎は、私がほぼ10年間使用してきたテンプレートと方法でした。もちろん、新しい技術を活用し、世界の変化に適応するために、絶えずレビューと更新が行われます。



仕事中に、「専門家」によって書かれた多くの資料を読みました。それらのほとんどは、理論を作成し、他の人に物事のやり方を教えるのが得意な開発者によって書かれましたが、独自の方法を決して実践しませんでした。その他は、狭い視野を持つ経験豊富な開発者によって書かれたものであり、この知識は特定のアプリケーションに大きく依存しています。開発者がこのような資料を読むと、問題を解決する方法は1つしかないと確信するようになります。開発者は、より広く考え、問題に対して説明された解決策は教義ではなく、単なる方向であることを理解する必要があります。



私がこれについて話しているのは、本当に価値のある何かを見つけてこれらのtrapに陥ることは非常にまれだからです。私が長年にわたって読んだ最高の資料の1つは2002年8月に執筆されたもので、Microsoftのテンプレートとテクニックです。これらは非常によく書かれており、ここや他の記事で説明した内容と一致しています。データ層コンポーネントの設計と層を介したデータの受け渡しに



注意してください。

おわりに

大企業の方向転換は、政治的でリスクの高い問題です。開発者の観点から見ると、一番下に移動して他の人がお互いを噛み合わせることは簡単です。私は、多くの開発者が彼らの実証された技術にノーと言うことを疑います。この記事では、既存のプロセスを再編成するためのいくつかのアイデアを提供するか、少なくとも通常は考慮されなかったいくつかのソリューションをより詳しく見ていきます。



説明したアプローチは、新しいシステムを構築する場合、またはシステムのすべてまたは一部を変更する場合に最適です。稼働中のシステムでは、何らかの事情により再構築が必要になるまで、何も触らない方が良いです。



UPD：プロンプトでmaovrnはDesign and Refactoringに移動しました。

UPD1：

タンクにいる人の場合：

1.Habréには、乗り換えの処理に関するルールがあります。ヘルプ

2を参照してください。アイテム1をマスターできない人の場合 この記事の著者はチャド・Zです。ハワー、別名クズ

3。始めと終わりなしで真ん中だけを読む人のために、この記事は3歳です。したがって、少なくとも、出版後に発表された資料の出版時に読まれなかった内容に基づいて、文盲の著者を宣言することは正しくありません。

4.この更新があなたに触れる場合-これらはあなたの問題です。