ウェブアプリケーションの構造について - かとじゅんの技術日誌
日経ソフトウエア 11月号の特集2で「最新Eclipseで良いJavaプログラムを書こう」に関連する話題として、さらに視野を広げて実用的なウェブアプリケーションでのレイヤー構造とかドメインオブジェクトの関係はどうなるのか？という点について解説してみたいと思います。(まだ日経ソフトウエア11月号を手にしていない方はぜひ買ってくださいw) 結論から先に出しますが、ドメイン駆動設計では一般論として下図のようなレイヤー構造やオブジェクトの関連が提唱されています。 ドメイン層のオブジェクトについては変わりないのですが、ドメイン以外のレイヤーに新しく２つのサービスが登場しているので、まずそこから簡単に説明します。 ドメイン層以外のサービス 実はサービスはドメイン層だけではなく、アプリケーション層とインフラストラクチャ層にも存在する場合があります。その役割を以下にまとめてみました。 レイヤー オブジェク
.NETの例外処理 Part.1 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
Archived MSDN and TechNet Blogs 2/7/2020 2 minutes to read MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. Archived blogs are grouped alphabetically by the initial letter of the blog name. Blogs and blog posts can be searched by their names, using the Search box at the top of the page. Actively updated blogs have been moved to other blog sites,
[ 技術講座 ] Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第2回 DDDの基礎と実践 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 本連載は、全3回の予定でEric Evansの書籍『Domain-Driven Design』（以降DDD）を紹介しています。前回はDDDの概要を説明し、第I部「Putting the Domain Model to Work」からDDDの基本原則となる3つのパターンを紹介しました。今回は続く第II部と第III部から、（アンチパターンを1つ含む）16のDDDパタ
Strategic Choice
Problemこのクラスは大きすぎて、もうこれ以上大きくしたくありません。「単一責務の原則」を適用してクラスを分割しようと思います。分割の具体的な方法がわかりません。Strategy「クラスの抽出」を適用します。どんなとき？「単一責務の原則」を適用してクラスを分割しようと思います。責務を把握したので、分割の実装を行いますが、具体的な方法がわかりません。どうする？「クラスの抽出」リファクタリングを適用します。ほとんどのレガシーシステムにおいて、最初にできることは、「実装レベル」で単一責務の原則を適用することです。つまり、大きなクラスから「クラスの抽出」をして、抽出クラスに委譲することです。「インタフェースレベル」で単一責務の原則を導入するには、より多くの作業が必要です。クラスの呼び出し側を変更しなければならず、テストも必要になります。まず、実装レベルで単一責務の原則を導入しておくと、将来イン
意図に関係する大事なことがら - かとじゅんの技術日誌
最近、DDDの"意図の明白なインタフェース"というパターンの章を読みなおしています。このパターンが一環して主張していることは"名前が重要"ということです。その名前の重要性について、いろいろな文献からの引用を用いて考えてみたいと思います。 名前重要 "名前が重要"といえば、「プログラマが知るべき97のこと」で、まつもと ゆきひろ氏が 「名前重要」というタイトルで名前の重要性について語っています。 適切な名前をつけられると言うことは、その機能が正しく理解されて、設計されているということで、逆にふさわしい名前がつけられないということは、その機能が果たすべき役割を設計者自身も十分に理解できていないということではないでしょうか。 名前が設計と強く結び付いていることがわかる、深イイ言葉です。 名前の決定が難航すると「えぃ、面倒だから適当に名前を付けてしまえ」となりがちです。油断すると結構適当になるもん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
