テーブル設計 データモデリングのエッセンス（５） | システム設計日記
ビジネスルールとは 業務を進める上で、さまざまな決めごと、約束事があります。 ・販売価格 ・１５：００までの注文は、翌日配送 ・７日前までのキャンセルは、キャンセル料を請求しない ・小口の注文は宅配便、大口の注文は、倉庫から直送 ・先着１００名は、１０％の特別割引をする ・和書と雑誌は、ポイントで割引はできない ・洋書はポイントで割引をする ・送料は商品種類にかかわわらずポイントで割引できる 業務アプリケーションでは、このビジネスルールを明確にして、実装することが、重要課題です。ビジネスルールがうまく実装されたシステムは、使いやすく、ビジネスの強力な道具になります。 ビジネスは生き物ですから、ビジネスルールは状況によって、変化します。この変化に短期間で低コストに対応できるシステムほど、ビジネスにとって、価値の高いシステムになります。 今回は、このビジネスルールの実装をデータベース中心で行う
抽象化のスキルアップ（発想の転換） | システム設計日記
設計の基本スキル「抽象化」の力のつけ方のヒント。 小さく・少なく・短く あるものを「抽象化」すると、結果は、 ・小さく ・少なく ・短く なる。 抽象化のスキルとは、「小さくする」「少なくする」「短くする」スキル、ということ。 目的はコミュニケーション 「抽象化」の目的は、関係者のコミュニケーションの良い「ネタ」や「道具」を提供することです。 大きくて、多くて、長いものは、コミュニケーションが大変ですよね？ １万行の一枚岩クラスなんて、読む気がしない。（読んでもわからない）。 どういうモデルで、どういう設計・実装になっているか、簡単に伝えるには、「１万行のコード」を「抽象化」して、「小さく」「少なく」「短く」説明すればいいんだ。 １００ページの仕様書を頭から読みはじめて、隅々まで読み込むのは、かなり大変。 誰か「要約」して、ポイントを教えて！ 「抽象化」スキルの出番ですね。 関係者とコミュ
Domain-Driven Design ドメイン駆動の設計 | システム設計日記
ドメイン(domain)の語源は、「支配している場所と」か「領地」という意味らしい。この線からこっち側はオレ様の領地、という感じですかね。 Domain-Driven Design(DDD)に、Bounded Context（コンテキスト境界）パターンがある。個々のドメイン（領地）の境界線をきちんとして、境界を越えて干渉しないようにすべし、という考え方ですね。これ、ドメインのもともとの意味を、再確認して強調しているだけなのね。 ソフトウェアは、何かを解決するために開発する。だから、ソフトウェア開発は、まず、その問題（の領域）を正しく理解することから始まる。そういう意味では、どんなソフトウェア開発も Domain-Driven Design なんだと思います。 まあ、問題領域の理解が浅かったり、関係者間で理解がばらばらだったりすると、悲惨な結果になるわけですが、ドメイン駆動というのは、ソフト
「自然キー」で識別するのが、もっとも「自然」 【パターン】 | システム設計日記
「自然キー」は、データモデリングの用語からの借り物です。 データモデリングの世界では、システム内部で機械的に発行する「人工キー」との対比で使われる用語。 「レコードを一意に識別するキーの候補には "自然キー" と "人工キー" がある、というように使われる。 自然キー( natural key ) は、名前、電話番号、メールアドレスなど、人間が使っている情報。 人工キー( surrogate key ) は、システム的に生成した番号。人間にとっては、意味のない情報。 人工キーは、人目に触れない、内部限定、というのが本来の意味らしい。 ここでは、「人間が使っている識別情報」を自然キー、システムで機械的に作成した番号を、人工キーとしておきましょう。 ソフトウェアのモデリングと設計・実装は、「自然キー」を大切にすべき。 自然キーは主キーとしては扱いにくい データモデリング的には、自然キーで、一意
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
