外部キー制約は何も考えずに適用するとよくない - かとじゅんの技術日誌
このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性
テーブル設計 データモデリングのエッセンス（５） | システム設計日記
ビジネスルールとは 業務を進める上で、さまざまな決めごと、約束事があります。 ・販売価格 ・１５：００までの注文は、翌日配送 ・７日前までのキャンセルは、キャンセル料を請求しない ・小口の注文は宅配便、大口の注文は、倉庫から直送 ・先着１００名は、１０％の特別割引をする ・和書と雑誌は、ポイントで割引はできない ・洋書はポイントで割引をする ・送料は商品種類にかかわわらずポイントで割引できる 業務アプリケーションでは、このビジネスルールを明確にして、実装することが、重要課題です。ビジネスルールがうまく実装されたシステムは、使いやすく、ビジネスの強力な道具になります。 ビジネスは生き物ですから、ビジネスルールは状況によって、変化します。この変化に短期間で低コストに対応できるシステムほど、ビジネスにとって、価値の高いシステムになります。 今回は、このビジネスルールの実装をデータベース中心で行う
ドメイン駆動設計読んだ - hitode909の日記
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
エリック・エヴァンスのドメイン駆動設計 - みねこあ
DDD Tシャツが欲しいので翔泳社で買うぞーっ！*1 ソフトウェアの核心にある複雑さに立ち向かう エリック・エヴァンスのドメイン駆動設計 ｜ SEshop.com ｜ 翔泳社の通販 しかし、なんでこんな書名になっちゃったかなぁ。シンプルに「ドメイン駆動設計」または ピアソンのC++の本みたく Domain Driven Design そのままのほうがカッチョよいのに、と思ってしまう。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (131件) を見る それにつけても翔泳社さんのラインナップは嬉しい次第。 *1:これもいいけど ネタT と
高木浩光＠自宅の日記 - 三菱図書館システムMELIL旧型の欠陥、アニメ化 - 岡崎図書館事件(7)
■ 三菱図書館システムMELIL旧型の欠陥、アニメ化 - 岡崎図書館事件(7) 21日の日記で示したMELIL/CS（旧型）の構造上の欠陥について、その仕組みをアニメーションで表現してみる。 まず、Webアクセスの仕組み。ブラウザとWebサーバはHTTPで通信するが、アクセスごとにHTTP接続は切断される*1。以下のアニメ1はその様子を表している。 このように、アクセスが終わると接続が切断されて、次のアクセスで再び接続するのであるが、ブラウザごとに毎回同じ「セッションオブジェクト」に繋がるよう、「セッションID」と呼ばれる受付番号を用いて制御されている。 なお、赤い線は、その接続が使用中であることを表している。 次に、「3層アーキテクチャ」と呼ばれる、データベースと連携したWebアプリケーションの実現方式について。3層アーキテクチャでは、Webアプリケーションが、Webサーバからデータベー
Domain-Driven Design ドメイン駆動の設計 | システム設計日記
ドメイン(domain)の語源は、「支配している場所と」か「領地」という意味らしい。この線からこっち側はオレ様の領地、という感じですかね。 Domain-Driven Design(DDD)に、Bounded Context（コンテキスト境界）パターンがある。個々のドメイン（領地）の境界線をきちんとして、境界を越えて干渉しないようにすべし、という考え方ですね。これ、ドメインのもともとの意味を、再確認して強調しているだけなのね。 ソフトウェアは、何かを解決するために開発する。だから、ソフトウェア開発は、まず、その問題（の領域）を正しく理解することから始まる。そういう意味では、どんなソフトウェア開発も Domain-Driven Design なんだと思います。 まあ、問題領域の理解が浅かったり、関係者間で理解がばらばらだったりすると、悲惨な結果になるわけですが、ドメイン駆動というのは、ソフト
[ 技術講座 ] 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パタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「ドメイン駆動設計」の複雑さに立ち向かう
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
なんとかDDをまとめてみた