Value Object の設計 - Aufheben - GLAD!! の日記
まずは、設計・実装における Value Object を整理した方が良さそうなのでまとめてみました。 Value Object の設計方法としては、以下の3通りがあると認識しています。 # 仕事で主に使用してきた言語が C++ と Java なので、もし他にもあればご教示ください。 1. Singleton インスタンスを1つしか生成しないパターンです。 Java の enum がこれに該当します。 同一性は == で判定することができます。 2. 不変オブジェクト インスタンスが1度生成されたら、属性の変更を許可しないパターンです。 Java のプリミティブ型のラッパークラス(Integer など)、String、BigDecimal などが該当します。 Java の場合、hash と equals メソッドをオーバライドする必要があります。 3. スコープ外へ公開する際に複製する クラ
Value と Entity - 感想 - Aufheben - GLAD!! の日記
昨日のエントリ id:aufheben:20090430 について。 概念って言っちゃったので話が難しい方向へ進んでしまいましたが、Value と Entity の違いが有効になるのは、やはり設計以降だと思います。Value と Entity を意識することで、不具合が発生しにくくなります。でも、不変性が Value の本質的な特性ではないと言われてしまうとわけがわからなくなってしまいます。そんなわけで、ちょっとこだわってみました。 ちなみに、Value って価値を表すものだから本当は重要なんだけれど、概念モデリングでは通常 Value は脇役です。Value を表に出すと概要がつかめなくなってしまうので。主役は Entity なんだけど、DDD はそこが弱いと思うので、僕は以下の3冊をおススメしています。 Javaエンタープライズ・コンポーネント―カラーUMLによるJavaモデリング 作
Value と Entity - Aufheben - GLAD!! の日記
きっかけは忘れたのですが、一昨日会社で Value Object の定義の話になって、Twitter でつぶやいたところ議論が盛り上がったのでログを残しておきます。 5/1追記: 個人的に重要だと思うところを太字にしました。あと、コメントを追記しました。 glad2121 少し頭痛が... 単なる寝不足か? Value Object で議論しすぎたか? glad2121 概念的な Value を「不変、かつオープンなもの」と仮に定義してみよう。1が2に変わったら、それは別インスタンス。製品の仕様みたいに、仮に不変であっても非公開な情報があればエンティティ。 glad2121 Entity は価値を保有する。Value は価値を定義する。 glad2121 Value にアイデンティティがないってほんと? Value 自身がアイデンティティじゃないのか? tadayosi @glad2121
Re:ドメインモデリングの需要 - Aufheben - GLAD!! の日記
id:aufheben:20090403 の続き。 システムへの要求はユースケースとドメインモデルで整理するのは良しとして、サブシステム分割、共通機能の洗い出し、コンポーネント分割など、全体のアーキテクチャを構築する過程で、共通性／可変性分析の手法として、フィーチャモデルが使えそうな気がします。 連載：次世代開発基盤技術“Software Factories”詳解 第3回 長期的な要求を定義するフィーチャ・モデル（1/2） - ＠IT 八角研究所 : Ruby on Rails によるシステム開発をモデリングで効率的に行う（3） - 分析・設計編（フィーチャモデリング） あと、これらのモデリングは事前にすべてやる必要はなくて、事前設計とリファクタリング、新規開発時と運用・保守開発時にバランス良く行うのが良いと思います。アーキテクチャのリファクタリングとか良い文献ないでしょうかね? 蛇足です
ソフトウェア開発におけるウェブベースのコミュニケーションにモデリングを導入する
こうした状況を踏まえて、筆者は2006年度下期未踏ソフトウェア創造事業にて、ウェブというコミュニケーションツールとの相性にフォーカスをあてたKodouguというモデリングツールを開発しました。本記事では、このKodouguの紹介をします。 開発拠点の分散に見られるコミュニケーションパターン Kodouguの紹介に入る前に、まずは開発拠点が分散したときによく遭遇するコミュニケーションのパターンを、特に成果物のレビューにフォーカスをあてていくつか紹介します。 出張による対面ミーティング 開発拠点が分散している場合、離れた拠点に出張してミーティングを行う場合があります。プロジェクト初期における重要な判断が必要な場合、トラブルが発生した場合などによく発生するパターンです。また、定期的に出張を行う場合もあるようです。 ミーティングの形式は単一拠点開発時のミーティングとあまり変わりませんが、出張時にミ
Martin Fowler's Bliki in Japanese - スケッチとしてのUML
http://www.martinfowler.com/bliki/UmlAsSketch.html この使用方法では、 開発者はUMLをシステムのある側面を伝えるのに使います。 設計図と同じように、スケッチをフォワードエンジニアリングやリバースエンジニアリングの方針として使うことが出来ます。 フォワードエンジニアリングでは、 コードを書く前にUMLを描きます。 リバースエンジニアリングでは、 既存のコードからUMLを作成し、 コードを理解しやすくします。 スケッチの肝は取捨選択が可能なところです。 フォワードスケッチングを行えば、 今から書こうとするコードのだいたいの項目を挙げて、 チーム内で話し合うことが出来ます。 スケッチを描くと、これからやろうとしていることについてのアイデアや選択肢を話し合うのに役立ちます。 すべてのコードについて話さなくてよいのです。 最初に同僚に説明したいと思
UMLのユースケース図における「include」と「extend」の意味について - OKWAVE
その本は持っていないため、読み方の問題なのか、本の記述の問題かはわかりませんが、 「必ず必要か」というのは、おそらく「定義の依存関係」についての説明のつもりではないでしょうか。 use caseの定義が別のuse caseに依存している＝「定義上で必要」であることと、「実行時に動く」ことは違うかと。 仕様上、<<inclute>>は、base use case(含む側)がincluded use case(含まれる側)に依存していて、 特定の場所で(部品として)included use caseの処理を含むものという定義です。 (主に共通利用を目的としているため、実行が無条件でも条件付でも無関係です) 一方、<<extend>>の定義では、base use caseは、特定のextension point(拡張点)により extension use caseが挿入されるとなっていて、ext
「Ruby on Rails によるシステム開発をモデリングで効率的に行う」連載記事を書いた - Akasata's Page（あかさたのページ）
2008-01-15 12:09 : 「Ruby on Rails によるシステム開発をモデリングで効率的に行う」連載記事を書いた 最近、八角研究所で技術記事を書いているのですが、そこで、Ruby on Rails の開発を潤滑に進めるために、モデリングを含めた開発プロセスを架空の事例に適用して紹介した連載記事を執筆しました。 この連載を書いた理由を簡潔に述べると、そろそろ Rails も平凡なエンジニアにとって使いやすくなるようにいろいろな道具立てをそろえていかないといけないと考えたからです。 最近、「Rails や Ruby 界隈の VB 化（別に Java 化でも Struts 化でも良いですが。）」というような話が語られています。入門時に敷居の高さを感じさせる Ruby ですが、Rails によってその敷居が低くなり、さまざまな人が Ruby/Rails に参入で
今日の気になったページ - 気まぐれなる日々
ユースケース図の extend は必要か？ http://www.hakkaku.net/articles/20071107-66 私が思うにはextendは、基本的に使わない方向で物事を考えたほうが良いと思います。但し、extendの使用が明確に説明ができる人はその限りではないと思います。 ユースケース図は単純な故に難しいと思います。単純だからこと曖昧や矛盾を排除しなければいけないわけですし。そうなると意外とユースケース図を描くのは大変な作業となります。敷居が低い分、簡単に間違った使い方する可能性があるわけで、その中で、extendを使用すると、結果的に理解しずらいユースケースが作成されてします。なので、使用法が明確に説明できないならばextendの使用は避けたほうが良い気がします。（あくまでも私の個人的思い）。 昔、ユースケース図のレビューを偉い方にしてもらった時、揚げ足取りかと思うほ
Enterprise Architect(EA) - 現場で闘う人のためのUMLモデリングツール
Enterprise ArchitectはUML 2.5,SysML 1.5,BPMN 2.0など、さまざまな表記方法に対応したモデリングツールです。 効率的なモデリングと数多くの支援機能の両方を提供し、販売開始から20年の累計では日本で約7万人が、全世界合計では100万人以上が利用しています。 広範囲をサポートする実用的モデリングツール Enterprise ArchitectはUML・SysML・BPMNなどの記法に対応するモデリングツールです。Visual Studioに似た操作体系に、「クイックリンク」に代表されるさまざまなモデリング支援機能を搭載しています。Enterprise Architectの持つ拡張機能を利用することで、UML・SysML・BPMN・DFDなどさまざまな表記方法を利用したモデリングが可能です。 Enterprise Architectは、設計開発で役に立つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Eric EvansがDDD（ドメイン駆動設計）を語る
Frieve Editor
はてなブログ | 無料ブログを作成しよう