NEC Cloud IaaS 設計パターン集: NEC Cloud IaaS | NEC
NEC Cloud IaaSを使ってシステムを設計・構築するお客様向けに、よくある利用パターンにおける設計方法や注意点などを分かりやすく解説したものです。 NEC Cloud IaaSをサーバ単体でご利用されるパターンから、他環境と組み合わせたハイブリッドクラウド利用パターンまで、さまざまなパターンをご用意しお客様のスムーズなサービス利用をご支援します。 NECの設計パターン集の特長 他クラウドとの連携、ハウジング・オンプレミスとの連携など、ハイブリッドクラウドの活用に役立つパターンを備えています。 無料でいつでも参照でき、NEC Cloud IaaSのスムーズな利用をご支援します。 注意事項 本設計パターン集は利用イメージや利用のポイントをお伝えするもので、詳細はサービス利用開始後に提供される文書（サービス仕様書、サービスガイド等）をご参照いただいた上で、ご利用いただくようお願い致します
概念モデルと論理モデルの違い（前編） - 設計者の発言
管理会計システムの開発ツール「FusionPlace」の開発者であり会計士でもある杉本さんが、９月の「第19回関西IT勉強宴会」でたいへん興味深い発表をされた。それを聞いて、私の中で曖昧だった「概念データモデル」の位置づけがはっきりして、「論理データモデル」との違いが浮き彫りになった。この快適なスッキリ感をおすそわけしたい。 ■従来の「概念データモデル」の危うさ これまで「概念データモデル」という用語は「対象領域における重要なテーブルのみを示したデータモデル」くらいの意味で使われていた。１ページか２ページに収まるように重要なテーブルのみを置き、しばしばキーが省略された形で示される。一部を示すとたとえばこんな調子だ。 以前に書いた記事「危ういデータモデルを見破るコツ」で、概念データモデルと呼ばれる図面の上に「多対多」のテーブル関連が現れることを批判した。一部のテーブルを省略すれば必然的に「多
危ういデータモデルを見破るコツ - 設計者の発言
ひところよりもデータモデル（ＥＲ図）を作成することの重要性が理解されるようになったが、それでも形だけ整えられて納品されてしまうことがある。「納品しろと言われたからしかたなく作った」ようなモデルはヤバい。素人のイラストにもとづいて高層ビルを建てるような無茶を避けるために、危ういモデルを事前に見破るコツを知っておこう。 ただし、データモデルの「意味的な正しさ」は個別の問題なので立ち入らない。ここではその「見かけ」から危ういモデルを見破るための３つのポイントを紹介しよう。「キー設計が甘い」、「多対多を含んでいる」、「他の設計要素を支えない」といった兆候があれば注意したほうがいい。それぞれを説明しよう。 １．キー設計が甘い データモデルはデータ項目間の「関数従属性」と「ドメイン制約」を示すための図面である。それゆえに、キー属性がいい加減に設計されたモデルは役にたたない。キーはテーブルの存在証明のよ
ドメイン層の構造の改善 ： Evolving Order パターン | システム設計日記
ドメイン層のオブジェクト群を、どういう視点で整理し、ドメイン層の構造を、どうやって育てていくか？ アプリケーション全体の構造 私たちのデフォルトのレイヤアーキテクチャは、 ■インタフェース （UI、REST API、... ) ■アプリケーションサービス ■ドメイン ■インフラストラクチャ（永続化、メッセージング） です。 アプリケーションサービスは、ドメイン層の薄いファサード。 実際の仕事は、ドメインのオブジェクトに委譲する。 ドメインで扱うデータの種類が増え、ビジネスのロジックが膨らんでくると、ドメイン層も、構造化して整理しないと、わけが分からなくなる。 初めはトランザクションスクリプトだった ドメイン駆動設計に取り組み始めたころは、ドメイン層の設計パターンは、ドメインモデルではなくトランザクションスクリプトでやっていた。 ユースケースごとに トランザクションスクリプトのクラスを作って
★DOAとXEAD Driverに関する私的な想い
データ指向設計（DOA)でテーブルと機能の仕様書を作成するだけで、 プログラミングせずに業務システムが動く というツールが ＸＥＡＤ Ｄｒｉｖｅｒ です。 夢のようなツールだと感じられるでしょうが、実は渡辺氏の最初の出版作である「 業務別データベース設計のためのデータモデリン...
MVCモデルの問題点を解決するPMモデルとMVPモデル - GeekなNooblog
MVCモデルについて - GeekなNooblog プログラマーが意識するべきUI設計指針 3つのMVCモデル - GeekなNooblog MVCモデルの問題点を解決するPMモデルとMVPモデル - GeekなNooblog MVCにおけるViewの表示方法 トランザクションスクリプト、ドメインモデル - GeekなNooblog 前回の続きです。 MVCモデルにはある問題が潜んでいると述べました。 問題点を述べる前に、MVCで作成されたコード例をを見てみましょう。 商品名、価格、在庫数が表示されており、購入を押すごとに在庫が減っていくという簡単なプログラムです。 今回はViewの振る舞いが重要になってくる話なので少しコードは長くなりますが、GUIで説明していきます。 MVCモデル(依存性を利用するMVC) コード行数を節約するためにObserverは自分で作成するのではなくJavaで用
設計の原則：モジュール化 | システム設計日記
ソフトウェア設計には、パターン理解が大切。 でも、その前に、設計の基本原則（設計の基本テクニック）を、押さえておきたい。 いろいろな設計パターンに共通する、その根っこにある設計原則を会得すれば、パターンの理解や実践が、もっと楽に楽しくなる。 設計原則の会得は、ソフトウェア設計の免許皆伝、達人への道であり、ここぞという時の、銀の弾丸になる。 モジュール化 たぶん、これが、いちばん基本の設計原則。 デザインパターンも、アナリシスパターンも、アーキテクチャパターンも、モジュール化原則の適用例になっていると思う。 モジュール化の原則違反の典型例は、一枚岩（モノシリック）で巨大なソフトウェア。 別名、密結合、スパゲティコード。 こういうソフトウェアは、理解しがたく、変更が恐ろしく難しい。 バグがあちこちに隠れていて、副作用が怖く、とてもじゃないが、コードを変更する勇気（度胸？）はない。 「一枚岩」は
ひがさんのBlogのまとめサイト (7) - 豆無日記
wikiroom.com 閉鎖 を読んで勉強するシリーズ第7弾 業務ロジック設計 DIContainerのない時代には、登場人物が増えると、それを管理するコストもばかにできないものになります。徹底的に役割に応じてクラスを分割するという手法が現実的になったのは、やはりDIContainerが出てきたおかげだと思います。 2004-12-23 - ひがやすを blog 今までの観点からするとやりすぎじゃないかってくらい徹底的にロジックを分割していくのは、DIによって簡単に各ロジックの依存関係を管理できるからなのだ、ということなんですね。 また、徹底的にインタフェースを活用していくことで、他のクラスの実装に依存することなく個々のロジックを実装・テストすることができると。 クラス/インタフェースの数は増えるが、その分個々のクラスの仕様/実装はシンプルに保つことができる。これがくーすの大きなアドバン
ひがさんのBlogのまとめサイト (6) - 豆無日記
wikiroom.com 閉鎖 を読んで勉強するシリーズ第6弾 業務ロジック層 Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。 こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、Statelessにすべきだと思います。その後は、 状態をドメインオブジェクトに変換して、ドメインオブジェクトのメソッドを呼び出すドメインモデルと 状態をDTOとして、業務ロジック層でそのまま処理するリッチな業務ロジックモデルの2パターンに分かれると思います。 2004-10-24 - ひがやすを blog ざっくりと勝手にまとめると↓。 Stateless: インスタンス変数を使わないクラス Stateful: インスタンス変数に状態を保持して、メソッド呼び出しでその値が変更になるクラス Statelessであればスレッドセーフなの
ひがさんのBlogのまとめサイト (5) - 豆無日記
wikiroom.com 閉鎖 を読んで勉強するシリーズ第5弾 今日は短めに。 TransactionScript (by Fowler) くーすでは、業務ごとにニーズなんか違うんだから、それぞれの業務ごとに、SELECT文は、最適化したものを使います。ある意味、SQLにロジックが埋め込まれているわけですが、RDBMSを使ってパフォーマンスを稼ぐには、それが一番だと思っているわけです。 これが、ドメインオブジェクトではなく、DTOを使うということにもつながってきます。 2004-10-21 - ひがやすを blog TransactionScriptが、扱うデータを一度に読み込み、ループでまわして、必要なものをセレクト、ということなら、くーすは違います。 最初から、SQLで必要なデータの必要な項目に絞って取得するからです。 Fowlerの言っているリッチなSQLですね。 SQLにロジックを
ひがさんのBlogのまとめサイト(4) - 豆無日記
画面遷移 2004-08-28 - ひがやすを blog 画面のモックを使って早い段階から顧客に具体的なイメージを抱かせて、意識違いをできるだけ減らそうと。 画面モック→画面遷移図と落とし込んで、イメージしやすい画面遷移図を作るとともに、画面モック自体で実際の動作を見せようと。 Singleton Singletonはテストと相性が悪い。なぜなら、テストメソッド間で状態を維持してしまうからだ。 2004-08-28 - ひがやすを blog 結構Singleton使ってました。 大体は設定ファイルの管理クラスで、読み込んだファイル内容をキャッシュしておくんでSingletonにしていただけだったんだけど、テストのときにモックに差し替えられないんで、ダミーの設定値を使いたいテストメソッドなんかで苦労した記憶が。 DTO プレゼンテーション層と業務ロジック層のデータのやり取りは、Entityや
ひがさんのBlogのまとめサイト (3) - 豆無日記
wikiroom.com 閉鎖 を読んで勉強するシリーズ第3弾。 設計 コントロール分析 2004-07-29 - ひがやすを blog くーすで、ロバストネス分析からコントロールクラスを抽出する方法。 以前よりちょっと手直しが入ってるそう。 ユーザ機能分析 2004-07-31 - ひがやすを blog FDDというのが良く出てきますね。Feature Driven Developmentですかね。 余裕があったら勉強してみようかな。 ここに簡単な説明が→Technologic Arts Incorporated | アジャイル開発。 Stateless BusinessLogicパターン。 これは、変更が多く、複雑な業務システムを開発するための銀の弾丸だ。しかし、幻ではない。 2004-08-05 - ひがやすを blog 今では幻になったくーす本構想。銀の弾丸、言いきっちゃったよぅ。
ひがさんのBlogのまとめサイト (2) - 豆無日記
(続き)AOP インターセプタは、自分自身の単体テストを行う。 アスペクトが組み込まれるクラスは、アスペクトを組み込まない状態で単体テストを行う。 結合テストでは、アスペクトがきちんと組み込まれていることを検証する。 インターセプタの細かいテストは単体で行われているはずなので、結合テストでのアスペクトの検証は正常ケース(そつうレベル)のみ。 で良いんじゃないかと思ってます。 横断的な関心がコアから分離されたので、テストも同じように分離し、結合テストでアスペクトの設定があってるかの検証は行うという考えです。 ぼくはDIContainerをダイコンと呼ぶね - ひがやすを blog まとめサイトにないけど、Tapestry系を追っかけてたら見つけたので。 これは本当にアスペクトで実装すべきなのでしょうか？ データアクセスはcross-cutting concernなのでしょうか？ 間違ってる！
ひがさんのBlogのまとめサイト - 豆無日記
こんなすばらしいまとめサイトがいまだかつてあっただろうか。 という感動の渦の中、一気読み。 wikiroom.com 閉鎖 自分用に、感銘を受けたところ、疑問点などポイントをピックアップしてまとめておこうと。引用先の改行とかスタイルとかは適宜修正してます。 なんか、 すでにお前のいる場所は我々は1年前に通過しているッ という感じで、ここ最近悩んでることとか、すでに議論されつくしている感が満載で、ワタクシちょっと非常にあせっております。 どの記事も内容が濃い上に記事の数が半端ではないため、まずはくーす時代の記事について追っかけてみます。 例外 catch禁止。間違いない。 2004-06-08 - ひがやすを blog うおお。強気だ。断言だ。 そうか、やっぱり最近のダイコン時代の流れはそうなっていくんですねぇ。 原則実行時例外ってのも結構衝撃でした。 「例外をキャッチしてすぐロギング」とい
RDBで階層構造を扱う方法 - プログラミング探して！
RDBで階層構造を扱う方法 † カテゴリーとか階層構造を持ったデータをMySQLで扱いたい。 どうすりゃいいのさ？ ↑ リンク † まずは、Google検索！ MySQL 階層構造 - Google検索 いろいろヒットしました！ リレーショナル・データベースの世界 http://www.geocities.co.jp/mickindex/database/idx_database.html http://mickindex.sakura.ne.jp/database/idx_database.html SQLで木と階層構造のデータを扱う（１）――入れ子集合モデル http://www.geocities.co.jp/mickindex/database/db_tree_ns.html http://mickindex.sakura.ne.jp/database/db_tree_ns.htm
ナチュラルキーを主キーにしてはいけない - 設計者の発言
定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー（一次識別子）に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、．．． いっぽうユーザの目に触れる項目は、「二次識別子」とされて
実行可能な仕様書は“設計できるプログラマ”が書く
実行可能な仕様書は“設計できるプログラマ”が書く：“実行可能な仕様書”を作る！（2）（1/3 ページ） 前回、「実行可能な仕様書」を実現するための鍵が「機能パターンの確立」だと述べた。それらのパターンを有効活用するためには、DBを正規化するとともに、ビジネスロジックを機能側からDB側に移行しなければいけない。そして、ビジネスロジックを的確に仕様化するためには設計スキルとともにプログラミングスキルが必要になる。 DBを正規化することのインパクト 前回、業務システムに含まれる機能（データ処理プログラム）をいくつかの「機能パターン」に整理することで「実行可能な仕様書」が実現可能になると説明した。機能パターンごとに仕様情報のデータ様式を定め、これを処理する「仕様翻訳エンジン」と「仕様エディタ」を用意すれば、「実行可能な仕様書」のための基盤が完成する。この基盤を便宜上「アプリケーションドライバ（アプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
汝の隣人のブログを愛せよ | LOVELOG
Symfony2でより良いソフトウェアを作るために
設計者の発言−渡辺幸三ブログ