DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
メディアマーカー
2019年5月31日をもちましてサービスを終了しました。 12年の長きにわたりご愛顧いただき誠にありがとうございました。
2010年05月10日の記事 | システム設計日記
情報システムが、全体として、健全に、成長し続けるための実践方法を、いろいろパターン（候補）として書いてみた。 ・成長し続ける全体 a growing whole ・将来像を語り続ける ・事業の言葉 enterprise language ・不健全さを取り除く ・ひとつずつ配置する ・周囲に気を配る ・人に気を配る これを、ひっくり返せば、それが、システムの成長を歪める、アンチパターン集になる。 成長を止める 【アンチパターン】 作ったまま、できるだけ手を加えない。 動いていて、使われているシステムに手を加えない、というのも、ひとつの考え方。 でも、システムは、手を入れ続けないと、かならず、腐敗していくと思う。 「現状の維持」というのは、幻想だと思っている。 成長を続けているか、腐敗が進んでいるか、どちらかしかない。 放置しておくと、システムは、必ず劣化していく。 利用者のニーズや事業環境は
ぼくが見ているレール(map.resouces編) - moroの日記
先日のQConで大場さんもおっしゃっていたことですが、Railsで開発をする上でものすごく重要なポイントに、Railsの敷いたレールから降りないというのがあります。別にコレはRailsが不自由だというわけでなく*1、通り一遍のものしかできないというわけでもなく、ただ基盤と相性の悪い設計すればあとで苦労するという、当然の話なわけです。 最近、私を含めいろいろな方が「レールから降りないで作るのが重要」と話しています。が。じゃあそのレールはどこにあるのかという話はあまり聞かれません。ということで、ふだん私がRailsアプリを設計するときに意識しているレールを言語化してみて、議論なりのたたき台にしたいな、と思った次第です。 とはいえDB周りは「羽生さんのERDレッスン嫁」で7割くらい済む話*2なので、まずはコントローラから。 設計指針としてのmap.resouces Rails 2.xにおいて、コ
BPMNを活用したビジネスプロセス・モデリング（1）：ビジネスを可視化するモデル記述言語「BPMN」 - ＠IT 情報マネジメント
ビジネスプロセスをモデル化するのに、UMLは難しすぎると考える人がいる。そもそも、顧客にUMLで記述したビジネスプロセス（のモデル）をみせてもなかなかわかってはもらえない。UMLはもう少し実装寄りのモデルを記述するのに使えばいい。ビジネス寄りのモデルを記述するために、もっと簡単で、しかも表現豊かな言語はないものか。簡単にいえば、そんなニーズのもとにBPMNは誕生したのである。（＠IT編集部） 連載を開始するにあたって 経営戦略とITが密接に結び付き、ビジネス環境の変化に合わせてビジネスプロセス（業務手順）を変更すれば、直ちにシステムが動き出す――。そんな夢のようなパラダイム・シフトが近づいています。その中心にあるのが最近注目されている2つのキーワード、BPM（ビジネスプロセス管理）とSOA（サービス指向アーキテクチャ）です。いま、その大きな流れの中に、BPMNというモデル記述言語が合流しよ
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
UML2メタモデルを読む－ 知識とは何か？
前回「ソフトウェアは知識の結晶」はソクラテス式対話編その2として「知識」とは何かについて考えてみました。 知識は学習と実践を繰り返して体で覚えるものである 知識は仕事の原動力である。仕事とは顧客に価値を生み出すことである。ゆえに知識とは価値を生み出す原動力である 知識は凝集させて結晶化させる人と結晶を解放して利用する人がいる。この結晶は利用者にとっての価値である この光り輝く結晶こそが（広義の）ソフトウェアであり、それは直接には目に見えないし手で触れない。しかし確かに存在するものである。存在を感知できる人にとっての価値である 今回はUML2仕様書を題材にして「メタモデル」を読みながら、あらためて「知識とは何か？」について考えてみたいと思います。 ［登場人物］ ソクラテス ソクラテスの弟子筋の某 司会 司会 UMLは知識を表現するための1つの道具です。UMLで表現されたモデルは知識の結晶です
第24回 アプリケーション設計と標準化（前編）
今回と次回はWebシステム基盤ではなく，その上で動作させるアプリケーションの設計について取り上げます。一般にWebシステム基盤の設計者（Webアーキテクト）とアプリケーションの設計者（アプリケーションSE）は別な担当者であることが多いのですが，アプリケーションはWebシステム基盤と整合性を取っていなければ正しく動きません。整合性を取るために，WebアーキテクトはアプリケーションSEの設計作業を支援することが不可欠で，設計支援するにはアプリケーション設計の知識が必要になります。 アプリケーション設計のポイントは，「アプリケーション・アーキテクチャ」と「アプリケーションの標準化」です。この2点に重点を置いて説明します。 アプリケーション・アーキテクチャ システム全体を見て描いたアプリケーションの青写真を「アプリケーション・アーキテクチャ」と呼びます。アプリケーションを設計する際には，システム基
コンテキスチュアル・インクワイアリーとは: DESIGN IT! w/LOVE
コンテキスチュアル・インクワイアリーとは、日本語では「文脈質問法」とも呼ばれる、観察を中心としたユーザー行動調査法の1つです。 ユーザー中心のデザイン・プロセスの初期段階での「ユーザーの利用状況の把握」に用いるユーザー調査法では代表的なものといえます。 プロセス上の位置づけを図示するとこんな感じです（詳しくは「人間中心設計（Human Centered Design＝HCD）で使う主な手法」）。 これまでこのブログではコンテキスチュアル・インクワイアリーについては、ばらばらと綴ってきましたが、このへんで１つまとめのエントリーを。 コンテキスチュアル・インクワイアリーの概要それでは、まずコンテキスチュアル・インクワイアリーの概要から。なかなか言葉だけで説明するのはむずかしいのですが、できるだけ簡潔に。 コンテキスチュアル・インクワイアリーはどのような調査法か？インタビューアが調査対象者である
人間中心設計（Human Centered Design＝HCD）で使う主な手法: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 人間中心設計（Human Centered Design＝HCD）を実施する際に用いる主な手法をちょっと整理。 これまでもユーザビリティ評価法としてのユーザーテストや、ユーザー要求の把握段階でのコンテキスチュアル・インクワイアリーなどを紹介しきてきましたが、全体像が見えないかなと思いましたので、あらためてそのあたりを整理してみようか、と。 人間中心設計で使う主な手法前にもすでに紹介していますが、ISO13407："Human-centred design processes for interactive systems"（インタラクティブシステムの人間中心設計プロセス）で国際規格化されている5つのプロセスをあらためて。 人間中心設計の必要性の特定利用の状況の把握と明示ユー
SEの「設計スキル」は低下しているのか
「SEの設計スキルが低下したのは“空白の10年間”のせいですよ」---。先日，大手ITベンダーの幹部に取材したところ，こう切り出された。 その幹部によれば，この10年間，大規模な基幹系システムの開発がめっきり減り，その代わりに保守開発や中小規模のWebシステム開発が増えた。そのために，「特に若手のSEが設計にかかわる機会が減少し，設計スキルの低下が目立つようになった」（同氏）と言うのだ。 ITプロフェッショナル12月号の特集では設計スキルを磨くために必要な方法論やパターンの活用，レビューの方法などを解説した。ここでは，その特集の前提となった「設計スキルの低下」について少し考えてみたい。 空白の10年がスキル低下を招いた ここで言う「設計」とは，システム開発プロセスにおける「基本設計」あるいは「外部設計」フェーズを指す。プログラムの内部構造を定義する詳細設計や内部設計は含まない。建築にたとえ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
