タグ

ブックマーク / watanabek.cocolog-nifty.com (5)

  • データモデルはドメインモデルに先行する - 設計者の発言

    関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD(ドメイン駆動設計)に関心を持つ技術者にとってお手になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ

    データモデルはドメインモデルに先行する - 設計者の発言
    surume000
    surume000 2022/07/04
    渡辺さんの記事がホットエントリー上がるの久しぶりだな。しかも7年前の記事か
  • OOUIは強力だが、合理的なDB構造を導くわけではない - 設計者の発言

    話題の新刊書「オブジェクト指向UIデザイン」を読んだ。使いやすいUIについては昔から興味があって手に取ったのだが、読みながら既視感につきまとわれた。かつてAS/400使いであった筆者は、90年代初頭に「アクション→オブジェクト vs オブジェクト→アクション」という話題で仲間と盛り上がっていたことがある。その内容がまさにこので書かれていたことだった。 「アクション→オブジェクト」とは古いタイプのUIで見られるパターンである。ワープロソフトが普及する以前、「ワープロ専用マシン」というものがあった。それを起動して最初に現れるメニューには、以下のようなメニューオプションが並んでいたものだ。 ・ドキュメントの追加 ・ドキュメントの複写 ・ドキュメントの編集 ・ドキュメントの削除 ・ドキュメントの印刷 たとえば「ドキュメントの編集」を選ぶと、ドキュメント名を入力・選択するためのダイアログが現れる。

    OOUIは強力だが、合理的なDB構造を導くわけではない - 設計者の発言
    surume000
    surume000 2020/07/23
    ほーん、その本読んでみよー
  • 「論理設計」にこだわる利点 - 設計者の発言

    業務システムのあり方を構想する際には、論理設計と物理設計とをフェーズ分けしたほうがいい。システム要件を仕様化しやすくなるだけでなく、スキル育成や効率改善の基礎となるからだ。それはソフトウエアの特性にもとづくプレゼントのようなもので、ありがたく活用したい。 そもそも「論理設計」とは何か。「受注情報だけを管理する」という単純なシステム要件があったとしよう。その際、たとえば以下のような「論理定義」がまとめられることになる。 1.業務構成 受注登録業務、受注保守業務、受注照会業務 2.データ構成 受注見出しテーブル、受注明細テーブル 3.機能構成 受注一覧機能、受注登録機能、受注保守機能、受注照会機能 ここでは定義要素の字面だけが示されているが、それぞれ独特な形式の詳細情報を伴う。たとえば「業務構成」は「いつ誰がどのようにこのシステムを利用するか」についての定義のまとまりなのだが、それぞれ「いつ(

    「論理設計」にこだわる利点 - 設計者の発言
  • 基本設計を分担してはいけない - 設計者の発言

    プロジェクトメンバーが無駄に多いのが、日型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ(意図された構造)が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と

    基本設計を分担してはいけない - 設計者の発言
    surume000
    surume000 2015/10/20
    例えがいちいちうまくて面白いですね
  • 動くシステムを営業段階で示せるか - 設計者の発言

    先日ある技術者とビールを飲みながら、興味深い話を聞いた。某有名SIerで働く彼はなじみの顧客から、ある開発案件に対して別のベンダーから提示された見積額が妥当かどうかを検証してほしい、と相談されたという。 さっそく彼は客先でシステムの仕様をヒアリングしてから、XEAD Modelerでざっとモデリングしてみたそうだ。というのも彼は、職場の仲間とXEAD(現X-TEA)の勉強会をしばらく前からやっていたからだ。それで、モデルがいい感じでまとまったし小振りなシステムだったので、モデルをXEAD Editorにインポートしてたちまち実装してしまった。その後に客先に出向いて「どう考えてもそれほどはかかりません。私たちならその半額でも請けますね」と説明したという。 なにしろ実際にシステムを動かしながらの説明だったので、効果は絶大である。ただし今回は案件獲得のためではなく、セカンドオピニオンの提供のため

    動くシステムを営業段階で示せるか - 設計者の発言
  • 1