3

モデル駆動型ソフトウェア開発。

私が理解しているように、ソフトウェアが実行しようとするドメインをよりよく反映するために、設計の抽象化レベルが上がります。

この方法論を機能させるには、ドメインの専門家 (顧客) と開発者の間のコミュニケーションが不可欠です。私が知りたいのは、MDSD の最初の推力に役立つツール スイートまたは一連のベスト プラクティスがあるかどうかです。ドメインが具体化されたら、そのモデルを ORM (またはその他) にマッピングするのはどうでしょうか?

MDSD と DSL の領域に飛び込んでいるので、建設的なアイデアやコメントを歓迎します。

4

5 に答える 5

2

Microsoft プラットフォームで開発している場合は、Oslo も確認してください。ここに素晴らしい概要があります: http://www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

ここに Chris Sells からの大量のリンクがあります: http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=2197

ドメイン駆動設計をモデル駆動開発と同一視する準備はまだ整っていません。

モデル駆動型アーキテクチャ (OMG MDA) をチェックして、独自のアーキテクチャを展開することはあまりないかもしれません。

モデル駆動型の大きな問題は、モデルから実装を導き出す専門知識がどこから来て、どのレベルのメンテナンス (およびデバッグ) で行われるかに関係しています。入手可能な本をテストするのは、パイプラインをどのように理解できるようにするか、モデリングから展開、そしてその逆の経路をどれだけよく理解できるかということです。

于 2008-11-04T20:44:09.667 に答える
2

.net でプログラミングしている場合は、Jimmy Nielsson による「Applying Domain Driven Design and Patterns」を読む必要があります。彼は、ORM (NHibernate)、SOA、および依存性注入に関するセクションも持っています。

いずれにせよ、Eric Evans による「Domain Driven Design」を参照してください。これは、ドメイン駆動設計のパターンとベスト プラクティスに関する貴重な情報を見つけることができるクラシックです。

于 2008-11-04T16:45:36.823 に答える
1

免責事項: 私はビジネス アプリケーションの開発者です。次の見解は、確かにエンタープライズ IT の塹壕での私の経験によって形作られています。私は、ソフトウェア開発の他の領域があることを認識しています。特に、産業用および/または組み込みシステムの開発では、世界が異なって見える場合があります。

MDSD はまだコード生成に結びつきすぎていると思います。

コード生成は、コードに多くのノイズが含まれている場合や非常に反復的な場合にのみ役立ちます。言い換えれば、コードが本質的な複雑さに集中できず、偶発的な複雑さで汚染されている場合です。

私の意見では、現在のプラットフォームとフレームワークの傾向は、偶発的な複雑さを取り除き、アプリケーション コードを本質的な複雑さに集中させることです。

したがって、これらの新しいプラットフォーム/フレームワークは、MDSD 運動の帆から多くの風を吹き飛ばします。

DSL (テキスト DSL) は、本質的な複雑さにのみ焦点を合わせることを可能にしようとするもう 1 つの傾向です。DSL はコード生成のソースとして使用できますが、主にコード生成に関連付けられているわけではありません。DSL (特に内部 DSL) は基本的に、実行時に解釈/実行できるようにします。[実行時のコード生成はその中間にあります]。

そのため、DSL が MDSD と一緒に言及されることがよくありますが、実際には DSL は MDSD に代わるものだと思います。また、現在の誇大宣伝を考えると、彼らは MDSD 運動から勢いを奪っています。

コードから偶発的な複雑さを最終的に取り除くという目標に到達した場合 (これは架空のものであることは承知しています)、ビジネス上の問題のテキスト モデルに到達したことになります。これ以上単純化することはできません!

素敵なボックスやダイアグラムは、抽象化レベルの別の単純化や昇格を提供しません! それらは視覚化には適しているかもしれませんが、それでも疑問です. 複雑さを把握するのに、絵は常に最良の表現であるとは限りません!

さらに、MDSD に関連するツールの現在の状態は、別のレベルの偶発的な複雑さ (同期、差分/マージ、リファクタリングなどを考えてください) を追加し、単純化の最終目標を基本的に無効にします!

私の理論の実例として、次の ActiveRecord モデルを見てください。

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

これ以上単純化できないと思います。また、ボックスと線によるグラフィカルな表現は単純化されず、これ以上の利便性は提供されません (レイアウト、リファクタリング、検索、差分などについて考えてみてください)。

于 2008-11-26T11:09:19.360 に答える
1

MDD は非常に複雑な場合もあれば、比較的単純な場合もあります。

さまざまなモデル (UML など) からコードへの変換を自動化し、エンジニアリングの往復処理などを行いたい場合は、かなり高度なツールを入手できます。

または

一方向 (モデルからコードへ) の変換を使用して、多かれ少なかれ手作業でモデルを描画し、コードを構築できます。

最初にモデルを構築するという考え方は、確立されたベスト プラクティスです。「デザイン」とよく言われます。設計と仕様を混同すると問題が発生します。構築されるもののモデルは、プログラミング仕様ではありません。これは、正確性の評価、テスト ケースの定義、仕様の記述などに使用できる抽象化です。

すべてをモデル化する必要はありません。特定の実装とは関係なく、データ モデルを用意することで MDD を開始できます。

  1. UML を使用してモデルを描画します。

  2. UML をクラス定義に変換します。

  3. ORM レイヤー (または ODBMS) を使用して、モデルをある種のストレージにマップします。

これ以上のものは必要ありません。やらなければならないことは、他の多くの問題に取り組む前に、モデルを正しくすることに集中することです。

この問題は通常、ソフトウェア開発中に発生するあらゆる種類の時期尚早な最適化から発生します。RDBMS 物理設計への早期の飛躍。早い段階で Web ページのデザインに飛び込み、それを使用してデータ モデルを推進します。サーバー アーキテクチャの定義とストレージの割り当てに早くから飛び込みます。

于 2008-11-26T12:07:28.010 に答える