4

完全に宣言的なドメイン モデル (DDD による) が可能かどうか、洞察/論文/記事などを探しています。

例えば：

  • 検証は宣言型にすることができます（多くのORMがこれを行います）
  • ビジネス フロー ロジックは宣言型にすることができます。ワークフロー / 有限ステート マシン / プロセス マネージャー / DDD サガ (呼び方は何でも) を定義するための DSL を Crud 操作で、おそらく ddd リポジトリを介して持つことができます。
  • 決定ロジックは宣言型にすることができます。つまり、ほとんどの場合、これは単純な条件に要約されます
  • 派生/計算フィールドは宣言的に行うことができますが、特にカスケードする場合は少し注意が必要です。つまり、計算フィールドなどに依存関係グラフを保持する必要がありますが、それでも実行できます。

実際にそれを試した人へのリンク、またはこれができない理由についての説得力のある議論はありますか?

ps: 「はい、できます。FSM は十分なメモリを備えたチューリング完全であるため、可能です」と答えないでください。

4

2 に答える 2

6

「ハンマーを持てば全てが釘」

可能かどうかを尋ねる代わりに、次のように尋ね てください。この特定のことを宣言的に行いたい理由は何ですか?

データの検証は、宣言的に行うのに適しています。DTO があり、いくつかの属性を追加すると、すべてが明確で読みやすくなります。

ビジネス フローが宣言的に行われる... Windows Workflow Foundation の大失敗を思い出します。実際に使っている人はいますか？振る舞い中心のコンポーネントを宣言的な方法で作成する利点は何ですか? 命令的な方法はこれに適しているようです。決定ロジック...多分。しかし、もう一度-なぜですか？

「派生/計算フィールドは宣言的に行うことができますが、少しトリッキーです」簡単なことで同じ結果を達成する方法があるのに、なぜトリッキーなことをしたいのですか?

なぜ？構成ファイルを編集して、実行時のアプリの動作を変更する必要がありますか? よし、やってみよう。

多くのクライアントが使用する一般的なドメインがあり、クライアントに合わせて再構成する必要がありますか? わかりましたが、ドメインの不変のコアとさまざまなものを明確に区別する必要があります。すべてのものを設定可能にしようとしないでください -インナー プラットフォーム シンドロームになってしまいます。

クライアントがプログラマーを必要とせずにドメインを変更するために使用できる宣言型言語を作成できると思いますか? いいえ、失敗します。私はこのような言語を知っています。通常の会計士がデータを探索するために使用する簡単な宣言型言語。それはSQLと呼ばれます:D

于 2013-10-03T11:27:33.357 に答える
3

Bartłomiej Szypelow の発言に完全に同意します。とにかく、私はあなたの質問に答えようとします。

宣言型言語は、機能するために常に命令型言語に依存しています。たとえば、算術のような単純なものを考えてみましょう。の結果を求めるとき、ステートメント全体を解釈する前に、まずをどのように理解すべきか、またそのコンテキストで演算子をどのように計算できる1+1かを知る必要があります。これは、複雑さを克服する方法の 1 つです。プラス演算を使用できるようにするために、プラス演算がどのように行われるかを知る必要はありません。1+

http://en.wikipedia.org/wiki/Imperative_programmingから:

手続き型プログラミングは、宣言型プログラミングへの一歩と考えることができます。プログラマーは、プロシージャーの名前、引数、および戻り値の型 (および関連するコメント) を見るだけで、特定のプロシージャーが何を行うべきかを、その結果がどのように達成されるかの詳細を必ずしも見なくてもわかることがよくあります。同時に、完全なプログラムは、実行されるステートメントとその実行順序を大幅に「修正」するため、依然として不可欠です。

どのドメインでも同じことが当てはまります。客室乗務員に尋ねるとreschedule、flight彼女はフライトと乗客が何であるか、そしてその方法を知っていますreschedule。したがって、スケジューリングがどのように機能するかを記述せずに、完全に宣言的なフライト スケジューリング ドメイン モデルを作成することは不可能です。すべてのドメイン モデルには操作/動作が含まれているため、たとえば、同様の方法で運営されている 3 つの航空会社がある場合など、問題のドメインが一意でない限り、宣言型言語でドメイン モデルを作成することは同様に不可能です。

理由に戻る...あなたは言った：

実際、仮想的な理由は、非コーダーが設定によって (些細な) バックエンドを作成できるようにするためです。

宣言型プログラミングは、命令型プログラミングより常に単純であるとは限りません。ほとんどの場合、人々は結果で考える傾向がありますが、結果が非​​常に多様であるため、段階的に考える方が (はるかに) 簡単な場合もあります。これが、これらの異なるスタイルが存在し、そもそも存在し続ける理由です。コーダーとノンコーダーの主な違いは、ノーコーダーがプロセスではなく結果の観点から考える傾向があるということではなく、ノンコーダーは単にコンピューターの動作に煩わされたくないということです。非コーダーは問題に集中したいと考えています。ドメインによっては、非コーダーは、宣言型 DSL ではなく、命令型 DSL を使用するのが最適な場合があります。

于 2013-10-05T16:10:06.140 に答える