開発アプローチ：ユーザーインターフェイスインまたはドメインモデルアウト？

Smalltalkを使って何も配信したことはありませんが、Smalltalkで遊んだ短い時間は間違いなくその価値を残しました。エクスペリエンスを記述する唯一の方法は、本来の方法であるMVCです。基本的に、アプリケーションのすべての面倒な作業は、ビジネスオブジェクト（または、その傾向がある場合はドメインモデル）で行われます。標準コントロールは、何らかの方法でビジネスオブジェクトにバインドされます。たとえば、テキストボックスはオブジェクトのフィールドにマップされます（フィールド自体はオブジェクトなので、簡単に実行できます）。ボタンはメソッドにマップされます。これはすべて非常にシンプルで自然なAPIで行われます。オブジェクトのバインドなどについて考える必要はありません。それは機能します。

しかし、多くの新しい言語とAPIでは、外部から考えることを余儀なくされています。最初はC ++とMFCで、そして今はC＃とWPFで、Microsoftはイベントハンドラーを実装してアプリケーションを構築するGUIビルダーに夢中になりました。Java Swingの開発もそれほど変わっていません。自分でフォームのコントロールをインスタンス化するコードを書いているのはあなただけです。一部のプロジェクトでは、ドメインモデルさえ存在しない場合があります-イベントハンドラーだけです。私はほとんどのキャリアのためにこのモデルの中とその周りにいました。

それぞれの方法で、あなたは違った考え方を強いられます。Smalltalkアプローチでは、GUIが愚かである間、ドメインはスマートです。デフォルトのVisualStudioアプローチでは、GUIはスマートですが、ドメインモデル（存在する場合）はかなり貧弱です。

私が仕事をしている多くの開発者は、Smalltalkアプローチに価値を見出し、そのアプローチをVisualStudio環境に押し付けようとします。WPFには、それを可能にするいくつかの動的バインディング機能があります。しかし、制限があります。ドメインモデルに属するコードの一部は、必然的にGUIクラスになります。

では、どのようにコードを設計/開発しますか？どうして？

• 最初にGUI。ユーザーとの対話が最も重要です。
• 最初にドメイン。UIを配置する前に、システムが正しいことを確認する必要があります。

どちらのアプローチにも長所と短所があります。ドメインモデルは、クリスタルの大聖堂と空のパイでそこに収まります。GUIは迅速かつ汚い（時には本当に汚い）状態で収まります。

さらにボーナスがあります：コードが保守可能であることをどのように確認しますか？

どちらでもない

長年にわたってソフトウェアを開発してきましたが、考慮すべき「中間点」が常にあるため、両方の最初の方法論を実践することになりました。UIコードとビジネスコードの間にインターフェイスを配置し、ドメインで現時点でUIに必要なものについて合意します。

この概念を明確にするために図を作成します。

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

そうすることで、UIが受信できるデータが明確に明確になった場合、UIとドメインモデルを別々に繰り返して作業できます。

一部のプロジェクトがメンテナンス不能になる理由は、データとプレゼンテーションの間のインターフェイスが急ぎすぎているか、存在しないためです（直接データ処理コードはUIにあります）。データベースコードがフォームコード内にある多くのプロジェクトを見てきましたが、人類への信頼を失いました。私が見た少数のプロジェクトだけが、この堅固な中間基盤を持ち、信仰を失った。

それは、そこから本当に問題ではないエンド何を重要なのあなたが持っているということです...あなたが最初に起動する場所その場所での懸念事項の明確な別離。中間のその契約は、手元のアプリケーションまたはシステムをほぼ定義しています。ボトムアップまたはトップダウンに進む前に、まずそれについて考えてください。

最初にドメイン。UIを配置する前に、システムが正しいことを確認する必要があります。

単純な場合を除いて、他に機能させることはできません。

UIから開始すると、壊れやすいバグの多いソフトウェアになりますが、これは面白そうに見えるかもしれませんが、モデルに深刻な問題があることがよくあります。

UIが最初に失敗する運命にあることは当然のことではありません。モデルが十分に単純であれば、モデルが最終的にうまく機能するという確信を持って最初にUIを構築できます。

モデルを簡単に想像できない場合は、まずモデルを構築する必要があります。

最悪のケースは、一部のプログラマーがモデルを想像できると考える場合です。重要な詳細、特殊なケース、例外、またはパフォーマンスの考慮事項が省略されている場合があります。GUIはすでに構築されており、多くの考慮事項が省略されているため、モデルはひどいものです。

これは実際のアプリケーションに依存します。

閉じたクライアント/サーバーアプリケーションを構築する場合は、どちらのアプローチでも十分です。フロントエンドのニーズに合わせてバックエンドを操作する必要があるためです。

潜在的なWebサービスを顧客が使用するために公開するオープンなクライアント/サーバーアプリケーションを構築している場合、フロントエンドを開発するために顧客がそのサービスをどのように使用できるかを認識することが重要です。

多くの場合、開発の小さな反復サイクル（スクラム、かんばんなど）のプッシュに関して、フロントエンドとバックエンドは並行して行われます。それは、その特定の反復に必要なものを提供することです。アプローチが必要な場合に備えて、ビルドを無視します。並行アプローチでは、開発全体で両端がずっと近くにあるため、フロントエンドとバックエンドがマージされるときに継続的な変更の必要性を軽減できます。可能であれば、これは私の好みのアプローチです。

あなたが言った...

... WPFには、それを可能にするいくつかの動的バインディング機能があります。しかし、制限があります。ドメインモデルに属するコードの一部は、必然的にGUIクラスになります...

あなたは何を意味わからないいくつかの？WPFとSLは両方とも、それらのバインディング機能で注目されています。無限です。MVVMベースのWPFアプリケーションのビュー内にコードを配置する必要がある場合は、何か対処する必要があります。添付ビヘイビアは、ビュー内のイベントに結び付けずにビヘイビアを実装する1つの方法であり、ビューをクリーンに保つためのその他の多くのアプローチも同様です。

ユーザーインタラクションのスタンスからのフロントエンドは、バックエンドの実装とは関係ありません。フロントエンドに対するバックエンドの唯一の仕事は、処理データまたは他の手段を介してデータを提供することです。これは、開発中のアプリケーションのタイプと結びついています。

ソースコードが維持可能であることを確認することは、それ自体がまったく異なる質問です。高レベルでは、次の実証済みのパターン、アーキテクチャ、およびテクノロジに加えて、ベストコーディングプラクティスに関連しています。

私は最初に基本的なUIを設計することを好みます（たとえそれが紙の上にある場合でも）、顧客からの入力で。顧客は、それを見るまで何が欲しいのか本当にわからないかもしれません。顧客があなたに言ったことを常に信用できるとは限りません。堅牢なドメインモデルの作成に数週間を費やすことで、UIプロトタイプを見始めた後、顧客が望むものに適合しないことがわかります。

私たちは、自動化されたテストでソフトウェアを動かそうとします。自動UIテストはかなり時間がかかります。コンソールでいくつかの値をチェックするスクリプトの方が簡単です。

そのことを念頭に置いて、ビジネスロジックをUIとは別にするように非常に注意しています。

かつてリード開発者から、すべてのビジネスコードをUIにバインドするのをやめる必要があると提案されたときに、ドキュメント/ビューアーキテクチャは時代遅れであると怒鳴ったことを覚えています問題は私たちの問題でさえなかった）。私は単にd然とした。

IMNSHO、少なくともビジネス層とUI層が存在しないという言い訳はありません。製品がやや興味深い何かをする場合、この分離がコードの再利用を可能にすることが絶対に必要です。

C＃開発者として、あなたが外で働くことに夢中になっているとは絶対に思いません。実際には、最初にドメインモデルを実行することを好みます。

WPFの場合、説明したモデルの唯一の欠点は、UIとドメインモデルを仲介する必要があることです。それでも、それはより多くの作業を意味する場合がありますが、よりクリーンなコードも意味します。

確かに、ドメインが最初です！

Smalltalkの美しさは、ワークスペースまたはインスペクタから「印刷」するなど、さまざまな方法でドメインモデルを非常に簡単に「駆動」できることでした。ドメインが期待どおりに動作していると確信した場合にのみ、完璧なGUIの構築に集中しました。

それは、Smalltalkersが2つで同時に動作しなかったということではありませんが、GUIがビジネスロジックの実装に失敗した場合、通常、GUIに特別なケースを置くのではなく、最初にドメインモデルを修正しました。