MSDN ホームページThis browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
連載：アプリケーション・アーキテクチャ・ガイド2.0解説 第5回 典型的なアプリケーションのパターン（前編） − ＠IT
●キャッシュ化 データや出力をキャッシュしておくことで、データの検索を高速にしたり、ネットワーク越しの通信のオーバーヘッドをなくしたりして、不必要な処理を排除することができる。ただし、不適切なキャッシュは逆にパフォーマンスに悪影響を与えるため注意が必要である。 注意点： よく変更されるデータはキャッシュしない。 データをキャッシュするときは、すぐ利用できる形式でキャッシュしておく。 比較的静的なページでは、出力そのものをキャッシュする。 ネットワーク接続などの共有リソースはキャッシュではなくプールする。すなわち、使い終わったら速やかに返却して再利用する。 もし更新データをWebサーバでキャッシュするのであれば、Webサーバがステートレスにならない。そのため、Webファーム構成をとる場合には同じクライアントからの要求を単一サーバに振り分ける（サーバ・アフィニティ）必要が出てくる。 関連するパ
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
)
.NET Architecture Center: The Architecture Strategy Series
Thank you for joining us at Microsoft’s Strategic Architect Forum 2015 Session videos and presentations are now available online See sessions, presentations and additional relevant content here Architecture blueprintsScenario-based diagrams that help you build new solutions fastWatch the videoTransform technology to an asset to grow your business and your career<iframe width="980" height="550" all
Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じ - プログラマの思索
Webアプリ開発で必ずぶち当たる課題、Webアプリ特有の技術、アーキテクチャについて考えてみる。 古くから続く課題を知れば、次世代Webフレームワークがどのように解決しようとして、何を提示しようとしているか分かりやすくなるだろう。 ＃以下、セキュリティ関係などを除く。 Webアプリは、Ajaxが登場するまで、UIがブラウザで制限されているため、それほど難しい機能を実装できなかった歴史があった。 古くはPer/PHP、そしてJavaに至るまで、Webアプリはステートレスだったから、殆どの機能は閲覧機能とマスタメンテナンス機能にすぎなかった。 なぜなら、Webアプリでは、6時間以上もかかるようなバッチ処理を実装したとしても非現実的だから。 しかし、以前から知られているアーキテクチャ上の課題はあるし、Ajaxの出現によって更にその課題が複雑になった現状もある。 Webアプリを作る時はいつも、下記
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
ITエンジニアとしての道を究めるには - 第5回 ITアーキテクトの道
さまざまな困難をどう乗り切ればいいのか ITエンジニアとしての道を究めるには 第5回 ITアーキテクトの道 萩本順三（豆蔵取締役） 2004/3/19 今回は、多くの企業が求め、多くの技術者があこがれるITアーキテクトについてお話ししたい。 ITアーキテクトという職種は、業界でその職種に対する意味が広く認知されているものではない。また、どのような技能やロールに対して名付けられているのかもあいまいな状況なので、本来「職種」と呼ぶのに少々ためらいがある。では、「技能」なのか。まあ、そのようなことは後回しにして、もっと重要なことから解説しよう。 筆者はITアーキテクトを現在のソフトウェア開発において必要不可欠なものだと考えている。 そこで、ここではITアーキテクトになり得る人材の特徴を分析し、なぜそのような人材が現代のソフトウェア開発環境で必要とされているのか、その技能とはいったいどのようなもの
階層化アーキテクチャと依存性注入・依存性逆転：CodeZine
.NET 1.0のベータ1から.NET Frameworkに従事してきた.NET開発のエキスパートで、アプリケーションのアーキテクチャ作成と設計と開発で7年以上の経験がある。アジャイルプラクティスと実際的なビヘイビア駆動開発（BDD）テクニックを通じてチームの成功を支援する独立コンサルタントとして活躍している。BDDを.NETに応用する記事をVisual Studio Magazine、DevX、MSDNに寄稿。ポッドキャスト/スクリーンキャストとして人気のある.NET Rocks!とDNRTVに登場したことがあり、実際のデザインパターンというトピックについてMicrosoftのためのウェブキャストを配信。MSDN Canada Speakers BureauおよびMicrosoft Most Valuable Professional（MVP）のメンバ。自分のブログも継続的に更新中。
４＋１ビュー
アーキテクチャは、システムの静的・動的両面の情報を持つ。アーキテクチャをモデル化するためには、何らかの整理された視点が必要になる。一例として、Rational Unified Process（RUP）におけるアーキテクチャ表現「4＋1ビュー」を紹介する。 RUPでは、開発プロセスに関与する特定の利害関係者（例えば、ユーザー、設計者、管理者、開発者、運用管理者など）がシステムに対して持っている各自の関心事項を扱うために「ビュー」を定義し、それらを総称して、「アーキテクチャー・ビュー」と呼んでいる。以下の5つのビューで構成される（視点の違いを加味して「4＋1ビュー」と呼ばれる。 以下、イタリック部分は「Rational Unified Process 2003」からの引用である。 ユース・ケース・ビュー アーキテクチャー上、重要な振る舞いやクラス、技術面でのリスクを含むユース・ケースとシナリオ
＠IT [FYI] ソフトウェア開発4つの課題（3）
企画：アットマーク・アイティ 営業企画局 制作：アットマーク・アイティ 編集局 掲載内容有効期限：2004年12月31日 ソフトウェア開発4つの課題 第3回 アーキテクチャについて アーキテクチャ基礎講義 日本IBM 藤井智弘 「アーキテクチャ」。この言葉が意味するものはあまりにも幅広く、その存在を正確に捉えている人はとても少ないようだ。今回はRational Unified Process（RUP）で定義されている「アーキテクチャ」を軸に、初心者にもわかりやすくアーキテクチャの真髄を解き明かしていく。キーワードは、コンポーネントとインターフェイスにある。（アットマーク・アイティ編集局） さて今回はアーキテクチャの話である。……とはいいつつ、魔物ですね、このテーマは。「ワンランク上のエンジニア」を対象とする記事では、よく“アーキテクチャ”という言葉を見かける。プログラミング作法ではなく、ア
特別公開！アーキテクチャドキュメント｜オブジェクトの広場
はじめに この記事では、以前私たちが実際に関わった開発案件で作成した「アーキテクチャドキュメント」を公開します。 別に国宝のお寺の庭に入れるわけでもないのに、「特別公開！」などという表現はずいぶん仰々しいな、と思われる方もいらっしゃるかもしれません。しかし特定のお客様向けに作成し納品したドキュメントを、そのまま外部に公開してしまうような例を、私自身はあまり聞いたことがありません。 これって結構特別だと思うのですが、手前味噌でしょうか？ システムの概要 ご紹介する開発案件の名称は「新石炭総合ＯＡシステム」といいます。これは、宇部興産株式会社殿で使われる社内システムで、在庫管理、販売管理などの機能を提供する典型的なビジネスアプリケーションです。 開発主体は株式会社宇部情報システム殿です。弊社（オージス総研）は、プロジェクトの立ち上げ期間の約３ヶ月間、２名が参加し、概念モデリングのコンサルティン
らくらく Unified Process - ライフサイクルモデル編 - 第 3 回 推敲フェーズを理解する | オブジェクトの広場
もしこれら 4 つのリスクに対して何も対応しない場合には、平均 2 ヶ月と少しのスケジュールの遅れ（すべてのリスクの発生確率 × 影響度の合計）が発生してしまいます。そのため、何らかの対応策を立案し、実施しなければなりません。だからといって、すべてのリスクに対応しなければならないかというとそういうわけでもありません。 リスク 3 のように発生確率が低いリスクは、実はリスクが発生しないかもしれません。そのようなリスクに対して、早期からリスク対応策を実施する必要はありません。その代わり、あらかじめリスク対応策を立案して、リスクの兆候を監視し、必要なタイミングでリスク対応策を実施に移すのです。 また、リスク 4 のように、リスクの被害（発生確率 × 影響度）と対応策にかかる期間がほぼ同じようなリスクについては、対応策すら立案せずにリスクを受容することも重要です。 このように、プロジェクトでは、リ
良好なレスポンスを実現するアーキテクチャ ― ＠IT
「ITアーキテクチャ構築の勘所」では、アーキテクチャ設計手順を示し、それぞれのステップにおける勘所を示した。その続編となる本連載は、ビジネス要求に応えるために必要な、「大量トランザクション処理」「24時間365日稼働」「使いやすい」といったシステムの特性に着目し、これを実現するためのITアーキテクチャ構築の勘所を述べていきたい。第1回の今回は「良好なレスポンス」を実現するアーキテクチャについて勘所を示す。 ITアーキテクチャ設計は、ビジネス要求に適切に応えるために、ビジネス要求に即したシステム特性を実現していく作業である。例えば、オンライン証券では多数の照会や売買の要求に対して迅速に応答する必要があり、このためにはクラスタリングやキャッシングをうまく適用したアーキテクチャ設計を行うとよい。 前回の連載では、アーキテクチャ設計手順を示し、それぞれのステップにおける勘所を示した。この続編となる
使いやすくて、変化に強いコンポーネント
前回「コンポーネント化でクラスをすっきり整理」は、パッケージとサブシステムによるコンポーネント化についてお話ししました。コンポーネントとは、どのように考えて作り上げていくのでしょうか。単純に似たようなクラスをまとめるだけでは、使いやすいコンポーネントにはならないでしょう。今回は使いやすく、保守しやすいコンポーネントを作るにはどのような考え方で設計するのかについてお話ししていきます。 コンポーネントとは 最初に、コンポーネント（部品）とはどのようなものか考えてみましょう。 自作パソコンを作ることを考えてみます。パソコンは電源ユニット、CPU、マザーボード、ビデオカード、メモリなどの部品から構成されています。製作者は、どのようなパソコンを作りたいかを考え、目的に合った部品を選択します。次に、それらの部品のインターフェイスを調べ、お互いのインターフェイスが合っているかを調べます。そして、実際に部
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MSDN ホームページ
http://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html
http://www.plaza.netchef.or.jp/watc_column.htm
大量トランザクション処理に適したアーキテクチャ ― ＠IT
[ソフト][アーキテクチャ]アーキテクトへの道 シリーズ 第一話