問題タブ [architecture]

DDD の背後にある概念を理解しようとしていますが、本を読んだだけでは理解するのが難しく、トピックについてかなり抽象的な方法で議論される傾向があります。コード、できれば C# での DDD の優れた実装をいくつか見てみたいと思います。

オープンソースの世界で DDD を実践しているプロジェクトの良い例はありますか?

.NETコミュニティ（ala Qi4j ）内のCOPについては、過去1年間にある程度の関心があったようです。数人の人々が独自のCOPフレームワークを導入しており（以下のリンクを参照）、.NET4.0のDynamicDispatchとMEFが.NETCOPフレームワークで潜在的な役割を果たしているように見えます。

一方で、これの多くはSystem / 38日からのアイデアを思い起こさせるように見えます（はい、私は老人です）が、他方では、オスロ（モデリングとリポジトリ）にもかなり適しているようです）。MicrosoftがCOPに取り組んでいるかどうかについて誰かがコメントできますか？

最近の.NETCOPフレームワークの取り組み：

HendryLuk-あなた自身のCOPをロールバックする

YvesGoEleven.com-警官-概念実証

AndersNorås-トリックまたは特性？C＃を使用した複合指向プログラミング

MagnusMårtensson- Unityアプリケーションブロックでの複合指向プログラミングの急増

Java での MVC Web アプリケーションについて非常に基本的な質問があります。

生の JSP の昔から Seam のような現在の技術に至るまで、非常に基本的なパターンは常に、最初に要求を受け入れたコントローラーから、クライアントに送信される出力を作成するビュー層への内部ディスパッチでした。

通常、この内部ディスパッチは、URL を使用してサーブレット コンテナーに新しいリソースを要求することによって行われます (構成の追加レイヤーによってメカニズムが隠されている場合があります)。これらの URL のマッピングは、外部への「実際の」URL も定義する同じ web.xml によって行われます。

特別な対策を講じない限り、ビュー レイヤーに直接アクセスできることがよくあります。"register.seam" をバイパスして直接 "registered.xhtml" に移動できる Seam "registration" デモをご覧ください。これは潜在的なセキュリティ上の問題です。少なくとも、ビュー テンプレートのソース コードが漏洩します。

これが基本的なサンプル アプリケーションにすぎないことは承知していますが、これらの内部リソースを外部から見えないようにするために特別な措置を講じる必要があることも奇妙です。

URL エントリ ポイントを制限する最も簡単な方法は何ですか?

内部要求によってのみアクセスできる魔法の URL パスコンポーネントである「WEB-INF」ディレクトリのようなものはありますか?

Java と Oracle の両方にDate と呼ばれるタイムスタンプ型があります。開発者はこれらをカレンダーの日付であるかのように操作する傾向があり、これが厄介な 1 回限りのバグを引き起こすのを見てきました。

1. 基本的な日付の数量については、入力時に時刻部分を単純に切り取ることができます。つまり、精度を下げます。ただし、日付範囲 (例: 9/29-9/30 ) でこれを行うと、これら 2 つの値の差は 2 日ではなく 1 日になります。また、範囲比較には、1) 切り捨て操作: start < trunc(now) <= end、または2) 算術: start < now < (end + 24hrs). ひどくはありませんが、DRYではありません。

2. 別の方法として、9/ 29 00:00:00 - 10/1 00:00:00という実際のタイムスタンプを使用することもできます。(午前 0 時から午前 0 時までなので、10 月の一部は含まれません)。現在、期間は本質的に正しく、範囲の比較はより単純です: start <= now < end. 内部処理では確かにクリーンですが、終了日は最初の入力 (+1) で変換する必要があり、出力 (-1) では、ユーザー レベルでのカレンダー日付のメタファーを想定しています。

プロジェクトで日付範囲をどのように処理しますか? 他の選択肢はありますか？Java側とOracle側の両方でこれをどのように処理するかに特に興味があります.

私は自分のコードを階層的に整理しており、次のようなコードを使用してツリーをクロールしていることに気付きました。

taskオブジェクトにドリルダウンしているわけではありません。私はその親にドリルアップしているので、カプセル化に関して何も失っていないと思います。しかし、心の奥底で、このようにするのは何か汚いことだというフラグが立っています。

これは間違っていますか？

32 ビット CPU では、整数は 4 バイトで、短整数は 2 バイトです。提供された短整数の範囲内に常に収まる多くの数値を使用する C/C++ アプリケーションを作成している場合、4 バイト整数と 2 バイト整数のどちらを使用する方が効率的ですか?

メモリから CPU へのバスの帯域幅に適合するため、4 バイト整数の方が効率的であると示唆されていると聞いたことがあります。ただし、2 つの短い整数を加算する場合、CPU は両方の値を 1 つのパスで並列にパッケージ化します (したがって、バスの 4 バイト帯域幅にまたがります)。

外部システムのイベントとタスクを、信頼できる/トランザクション的な方法でキューに入れる必要があります。MSMQ や ActiveMQ などの使用は非常に魅力的に見えますが、トランザクション部分は複雑になります (MSDTC など)。

データベース (SQL Server 2005 以降、Oracle 9 以降) を使用して、より簡単なトランザクション サポートを実現することもできますが、キューイング部分は見苦しくなります。

どちらのルートもそれほど素晴らしいようには見えず、厄介な落とし穴やエッジ ケースでいっぱいです。

誰かがこの問題について実用的なガイダンスを提供できますか?

考えてみてください: E/C/A またはスケジュールされたタスク エンジンが頻繁に起動し、現時点で実行する必要があるスケジュールされたタスクがあるかどうかを確認します (つまり、次の実行日は過ぎていますが、有効期限はまだ過ぎていません)。達した）。

ここでは私は例外かもしれませんが、3 人以上の開発者または 5 人以上のチームで働いたことはありません。それでも、なんとか仕事をやり遂げることができました（何とか）。

この「極端な」シナリオに適合するソフトウェア開発プロセスはありますか? また、スタンドアロンのプログラマーとして働いている場合、日常生活をより予測可能にし、一貫性を持たせ、文書化し、仕事を終わらせるために日常生活に適応できるものはありますか?

私は一連の数値に計算を適用するシステムを導入しています (詳細はあまり関係ありません)。システムユーザーが適用できる計算セットが多数あり、新しいセットが頻繁に追加されます。現在、新しい計算セットをシステムに追加する必要がある場合、それらはコード ベースに追加され、システムの新しいバージョンがリリースされます。まったく新しいバージョンをリリースすることなく、新しい計算セットをシステムに追加できるようにしたいと考えています。また、これらの新しい計算がシステム ユーザーに自動的に表示されるようにしたいと考えています。現在、計算セットごとに新しい関数が作成され、適切な関数名を含むレコードがシステム テーブルに追加されます。これらのレコードは、リストからそれらを選択するシステム ユーザーに表示されます (関数名にはもちろんエイリアスが付けられます!)。

これは私が継承した VB6/Access アプリで、現在 VB.NET と SQL Server で書き直しています。

これを行う最善の方法についてアドバイスはありますか？

Struts、Spring、Hibernateを使用する大規模なJavaアプリを継承しました。私が毎日扱っているクラスとインターフェースは、Strutsアクション、Struts ActionForms、値オブジェクト、サービスインターフェースと実装、DAOインターフェースと実装、およびエンティティです。ActionForms、Value Objects、およびEntitiesの間の責任の正しい分離について確信が持てないことを除いて、これらのほとんどの方法と理由についてはかなり明確です。また、ドメインモデル（つまり、すべてのエンティティ）には、実際のビジネスロジックが（あるとしても）あまり含まれていないことにも言及する必要があります。これは本質的にCRUDアプリであり、実際のロジックのほとんどはデータベースにあります（うん！）。とにかく、私が疑問に思っているいくつかの明確なJava関連の問題があります。

1）エンティティと値オブジェクト（VO）の間に大きな違いはないようであり、どちらかの方向にサービスレイヤーを通過するときに、他のオブジェクトに変換するために多くのコードを記述する必要があります（Strutsアクションは処理するだけです） VO、DAOはエンティティのみを扱います）。したがって、VOとエンティティはやや冗長に見えます。なぜ両方を持っているのですか？

2）VO <->エンティティ変換コードはどこに配置する必要がありますか？サービスレイヤー、エンティティ、VO？

3）VOはActionFormsに直接配置され、JSPのタグに直接バインドされます（例）。これは良い習慣ですか？そうでない場合、適切なデザインは何ですか？

4）値オブジェクトで外部キーの依存関係を適切に処理する方法が不明です。たとえば、特定のVOには、データベース用語で、タイプテーブルへの外部キー関係を表すタイプフィールドがあります。UIでは、これは、ユーザーがタイプを選択できるドロップダウンフィールド、またはタイプのテキスト表現を単に表示するラベル（画面によって異なります）に変換されます。さて、VOには、タイプID、タイプのテキスト表現、またはその両方のプロパティが必要ですか？誰がいつ、2つの間を翻訳する責任がありますか？

5）VOには、データベースIDのフィールドがあります。VOにはアイデンティティがないと思いましたか？これはどうしたの？

これらの質問が一般的な関心を引くのに十分一般的であることを願っています。これは、このタイプのアーキテクチャでは常に発生するようです。

また、このアーキテクチャはこのアプリにとって非常に重いのではないかと疑っています。より良いアーキテクチャについて提案がある場合は、先に進んでください。ただし、別のアーキテクチャは長期的なリファクタリングであり、現在は実行できないため、主に上記の質問への回答に関心があります。