地域、通貨は値オブジェクトかエンティティか?
でも、多くのシステムではCOBOL時代やC/S時代の慣習から必要以上のものをテーブル上でマスタ管理している傾向はあると思う。これは世界的な傾向だが、日本ではアプリPGの地位がとくに低く、プログラム中で書かれている内容がDB表に比べて信頼されないということにもよるかも#DDDjp
2011-05-04 19:45:29プログラマーの観点も考慮に入れ、DDDで設計し、本当にエンティティとしてマスタ管理すべきデータと値オブジェクト(enumを含む)としてコードで管理すればよいものを切り分けることで、性能面やメンテナンスコストを向上させられると思う。#DDDjp
2011-05-04 19:48:13マスタテーブル系で一番酷いと思ったのは、メッセージ系。「DBへの接続に失敗しました」というメッセージがDBで管理されている不思議
2011-05-04 19:51:24@shuji_w6e DDDの7章の例ではエンプラセグメントをあえて貨物の属性にせず、サービスに生成させることで柔軟性を高める設計になっていますね。なんでもDBに入れるという発想をやめることで、本来はもっと柔軟な設計が可能だと思います。#DDDjp
2011-05-04 19:51:37@shuji_w6e 日本人SEはやはりコードより表が大好きなのでしょうかね。Excel好きなのと同じかもしれません。もちろん、DB管理することで動的に設定値を変更したいなどはありますが。
2011-05-04 19:53:09なんでもかんでもマスターテーブルにいれると、単純な問い合わせのSQLが大変なことになるわけで・・・。何十もjoinした恐怖がよみがえるw
2011-05-04 19:54:56@ryoasai74 運用に入って初期の開発者がいなくなった後で,表示用の文言とかを簡単に変更したいって要望から DB で管理されてるケースが多いような.ユーザ側 (システム部門とか) の人達が自ら修正したプログラムは信用しにくいということはあるかもしれない.
2011-05-04 19:55:01@koichik @shuji_w6e いずれにしてもDDDではミスマッチを減らすために理想的にはDBをオブジェクトの格納庫と考えたいところがあるので、DBAとの対立は解決しなくてはならない問題でしょうね。#DDDjp
2011-05-04 19:57:34@ryoasai74 未だにExcelから業務アプリを生成できる、みたいな幻想もありますね。できる範囲はあるかもしれませんが
2011-05-04 19:58:21ほほー、これがSIer的発想か。マスメンでも立派な一画面ですからね。#DDDjp RT @shuji_w6e: @koichik それもあるけど、マスタ系の管理画面で見積もりを高くしていくためだ、とぶっちゃけ言われたこともありますw
2011-05-04 19:58:54@shuji_w6e その手のテーブルは初期化時に読み込んでしまうから,後で DB との接続ができなくなってから使う場面があるのでは.そんなにおかしくないと思うけど.別の DB との接続とかあるかもだし.プロパティファイルに「プロパティファイルの読み込みに失敗しました」は変?
2011-05-04 20:22:31@koichik 自分の経験では初期化時にロードしてOKだったのは3/7くらいですね。他は、「マスタの変更は即時に反映されなくてはならない(キリッ」と譲って貰えなかったorz
2011-05-04 20:24:42@koichik マスタ画面からキャッシュ更新なパターンは自分も経験あります。反映までのラグがある(笑)と、ゴネられましたけど・・・
2011-05-04 20:32:07色という値オブジェクトの Identity が GRB か CMYK かというのは,どちらもオブジェクトの抽象表現というだけで,Identity はそのオブジェクト自身.int の 10 と 0xA は違う表現だけど同じ値.
2011-05-04 20:36:00ERで値とエンティティの区別はしないってのは違うんじゃないかな.あちらでは値型にドメインという名前があるし,標準 SQL でも create domain って一応あるし.使ったことないけど.
2011-05-04 20:49:39