データ モデリングの問題 (一般的に行われている)

ブログテンプレート31

アレックスブログ画像
すべての成熟した MVC アプリケーションには、制御不能に成長した 20 つのモデルがあります。 テーブルには XNUMX 列があります。 システム情報とともにユーザー設定が保存されています。 電子メール通知を送信し、他のモデルをデータベースに書き込みます。 このモデルには非常に多くのアプリケーション ロジックが含まれているため、新しい機能はこのモデルを通過する必要がある可能性があります。 これは、開発者が開くたびに唸らせるクラスです。
どのように我々はここで手に入れたの?
Web アプリケーションは通常、単一の種類のデータを表示するという単一の目的から始まります。 記事 オンラインジャーナルの場合、または 衣類アイテム ファッション小売業者向け。 MVC 実践者は、製品のホワイトボード セッションからコンセプトを取得し、それをデータベース モデルに直接変換するのが一般的です。 したがって、アプリケーションの中心的な概念を表すデータベース モデルから開始し、より多くのビジネス要件が出現するにつれて、それらに対応する最も安価な方法は、既存のモデルに列を追加することです。 これを時間をかけて実行すると、最終的には次のようになります。 神のオブジェクト。
当初からの問題は、製品レベルで概略的に描かれたカジュアルで緩いコンセプトをコードベースに組み込むことでした。 ソフトウェア エンジニアは、人々が日常生活や思考で使用する概念が非常に不正確で、暗黙の仮定が含まれていることをよく認識する必要があります。 暗黙の前提を強調することは、多くの場合、ソフトウェア エンジニアの重要な貢献であるため、私たちがこれらの概念を製品レベルから取り出してコードに埋め込むのは不思議なことです。 それは、既存のクラスに押し込まれたロジックを明確にする必要がある隠れたエッジケースを求めているだけです。
の概念 民俗心理学 ここを照らしています。 民俗心理学とは、動機を推測したり行動を予測したりするために使用する、他の人間がどのように行動するかについて人々が持っている生得的で大まかに特定された理論を指します。 これらの「民間」理論は、人間の日常生活の文脈では十分に機能しますが、科学的に厳密ではなく、盲点が含まれています。 同様に、人々はソフトウェア ビジネスでも「フォーク オブジェクト モデル」を利用します。 これらは、人々が他の人とソフトウェアについて話し合うために構築する非公式の概念です。製品マネージャーがソフトウェア エンジニアに対して使用する言葉であり、ボックスはホワイトボードに描かれています。 他の人間と概念について議論する場合には十分に機能しますが、解釈には寛大でも、コードとして形式化するとバラバラになる可能性があります。 これらの概念は、製品の機能を構成するための出発点として役立ちますが、オブジェクト指向の観点から見ると、クラスとして使用するには広すぎます。 これらは問題領域の大部分を暗黙のうちに包含するため、ロジックが蓄積される傾向があります。
コードを学習する際に人が乗り越えなければならない最初の障害は、自分の考えを取り入れて、それをアルゴリズムのステップとして明示的に定式化することですが、経験豊富なソフトウェア エンジニアは、フォーク オブジェクト モデルを取得し、それをクラスとして使用できる明示的なコンポーネントに分解する必要があります。 。 製品ドメインでは、広範な「ユーザー」概念から始めるかもしれませんが、さらに深く掘り下げていくと、請求設定、現在のステータス、通知設定など、別のクラスとして機能する方が適切なさまざまなロジックが見つかるでしょう。 これらのそれぞれには、製品要件を満たすために独自のロジックが必要であり、ロジック用のスペースを確保するためにそれらを分離しないと、肥大化が発生します。
データ モデリングはビジネス概念をソフトウェアにエンコードすることであるとよく考えられていますが、実際にはシステムを構築するためのツールとしてモデル クラスを使用することです。 多くの場合、大規模なモデルがドメイン ロジックの特定の部分に対応するコンポーネントに分割されると、コードベースの機能が向上します。

著者

  • Adam McKenzie

    アダムは CTO として、HPC チームとカスタマー サクセス チームの管理を担当しています。 アダムはボーイングでキャリアをスタートし、787 年間 XNUMX に取り組み、主翼の設計、分析、最適化を行う構造およびソフトウェア エンジニアリング プロジェクトを管理しました。 アダムはオレゴン州立大学で機械工学の学士号を優秀な成績で取得しています。