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） - 分析・設計編（フィーチャモデリング） あと、これらのモデリングは事前にすべてやる必要はなくて、事前設計とリファクタリング、新規開発時と運用・保守開発時にバランス良く行うのが良いと思います。アーキテクチャのリファクタリングとか良い文献ないでしょうかね? 蛇足です
仕事で使いそうな標準規格 - Aufheben - GLAD!! の日記
しばらく前にまとめた資料です。 http://homepage2.nifty.com/glad/dev/standard/Standards.pdf
ICONIX - Aufheben - GLAD!! の日記
ちょっと思うところあって ICONIX プロセスについて調べてみた。 ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series) 作者: ダグローゼンバーグ,ケンドールスコット,Doug Rosenberg,Kendall Scott,長瀬嘉秀,今野睦,テクノロジックアート出版社/メーカー: ピアソンエデュケーション発売日: 2001/11メディア: 単行本購入: 1人 クリック: 38回この商品を含むブログ (28件) を見る 分析クラスを boundary、control、entity (BCE) と分類することがよくあります。 自分は、ユースケースをどのようなコンポーネント構成で実現するか、また各コンポーネントが果たすべき責務は何かを整理する道具として、BCE のクラスを使用するのですが、ICONIX の手法はちょっと異なるようです。
PSLX 業務オブジェクトモデル - Aufheben - GLAD!! の日記
仕事の関係で PSLX (Planning and Scheduling Language on XML specification?) について調査しています。 http://www.pslx.org/jp/ 製造業の業務のリファレンスモデルを作成しようという試みと受取りました。業務アクティビティモデル、業務オブジェクトモデルなどが定義されており、IEC62264 として国際標準化も進められているようです。 仕様書 (勧告版) を入手するには会員になるか購入する必要がありますが、業務オブジェクトモデルについては、以下のページから第2版の委員会投票用資料をダウンロードすることができます。 http://www.pslx.org/jp/forum/technical.html 製造業の業務が「資源」「プロセス」「オーダ」などの概念で整理されており、製造業の仕組みを理解する上でとても参考になり
IPA未踏成果報告会 - Aufheben - GLAD!! の日記
http://www.mitou-chiba.org/ ＠東京工業大学 大岡山地区西9号館1階デジタル多目的ホール 休暇をとって丸一日参加してきました。 # 裏番組も少し気になったけど... 前日の台風も上がり、参加者もまずまずでホッとしました。 SELinuxによるPostgreSQLのアクセス制御強化 まず、日立ソフトの中村さんによるゲスト講演「SELinux チュートリアル」、続いて海外さんによる成果発表。 素の Linux は root 権限を乗っ取られてしまったらおしまい。SELinux (Security-Enhanced Linux) ではきめ細かなアクセス制御が可能。Linux カーネル 2.6 から標準搭載されている。 SELinux で利用可能なアクセス制御モデルは、TE (Type Enforcement)、RBAC (Role Based Access Contro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
