Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>
「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と
ValueObjectは好きですか？私は大嫌いです。いじょ。 ざっくり言えばプリミティブ型に専用の型を付ける教義です。例えばUserIdをintとして扱っているとTeamIdと取り違えるかもしれないし、Hpに突っ込んでしまうかもしれない。StrengthとIntelligenceとAgilityとSpeedは別物なのだから全部intじゃなくて区別して欲しい、そうじゃないと間違った演算しちゃうぞ、と。まぁそういう自体を避けるために、それぞれラップした個別型を作るのです。int strengthじゃなくてStrength strengthだぞ、と。 これは一見正しく実際正しいのですが、問題もあります。一つに面倒くさい。ラップしたctorを作るのだけでも定形でウザ、と思いますが、更に等値とか実装するのは面倒くさい。また、そのままだと計算できなくなるので、算術演算のために生の値を.Valueで取り
composed_of を使って Rails で値オブジェクトを扱う - Sansan Tech Blog
DSOC サービス開発部でエンジニアをしている石畑です。普段は Rails で名寄せサービスを作っています。 今回は Rails で値オブジェクトを扱うのに ActiveRecord の composed_of が便利なので、紹介します。 値オブジェクト 値オブジェクトは DDD でも紹介されている概念です。多くのわかりやすい解説が世の中にあるので、詳しくは検索してもらえればと思いますが、ものすごく大雑把に説明すると「各属性で等価を判断できる不変なオブジェクト」です。 例えば「とあるスーパーでお肉を売る」を考えたときに、最初「300 円」で売っていた「お肉 A」を途中タイムセールで 100 円引きの「200 円」で売ったとしても「お肉 A」は値段を変更する前と「同一のお肉」です。 お肉のセール そのため、「お肉」の同一性は属性で判断することはできず、バーコードのような識別子で同一性を追跡し
今日は 『ドメイン駆動設計#1 Advent Calendar 2019』の 11日目 です。 昨日は mejileben さんの 『Laravelでドメイン駆動設計を実践し、Eloquent Model依存の設計から脱却する』 でした。 みなさん初めまして、こんばんは！ C# をこよなく愛する静岡エンジニアの t2-kob です。 本日のテーマは、 「DDD に入門するなら、まずは ValueObject だけでもいいんじゃない？」 です。 ■ なぜこの記事を書いたか？ ・理由の1つ目は、勉強のためアウトプットしたいと思ったからです。 最近 DDD コミュニティの DDD-Comunity-jp(Discord) に参加して、色々なオンライン勉強会に参加させて頂いています。 この勉強会へは色々下調べして臨んでいますが、その後の振り返りが出来ていませんでした。 このため、勉強を兼ねてアウト
ValueObjectという考え方 - Qiita
以前、DDD（ドメイン駆動開発）を経験した流れでいくつかのことを学びました その中でDDDの神髄を垣間見たのでかいつまんで紹介できればと思います 記事のターゲット DDDを学び始めた人 値オブジェクト・ValueObjectとはなにか、その片鱗を知りたい人 Value Objectとは 値オブジェクトとしてエリック本(青本)では紹介していますね Value Objectの特徴 特徴として以下のような内容があります 一意性を持たない 計測／定量化／説明を責務とする イミュータブルオブジェクト 交換可能 ふるまいに副作用がない 一意性を持たない オブジェクト毎に hogehoge_id のような一意性を表現するプロパティを含まず、一意性がない特徴です 逆にIDを持つようなオブジェクトは「Entity」といいます この特徴の意味するところはオブジェクトをプリミティブライクに扱えることだと考えられ
またまたValueObject、そしていよいよRoleについて
杉本啓 @sugimoto_kei 配賦計算やら外貨換算など計算処理が主題になる場合、Allocator とか CurrencyTranslator といった動詞的オブジェクトを作ることに、僕はあまり抵抗がない。配賦計算は、配賦される金額に属する訳ではないし、配賦割合に属する訳でもないと思うから。こういうのを嫌う人は多いのかな。 2019-10-12 18:57:11 杉本啓 @sugimoto_kei 配賦計算というコンテキストがあって、配賦対象金額や配賦率といった概念が生まれるのであって、その逆ではないと思うのな。DCI的に言えば配賦金額や配賦率は配賦計算というインタラクションにおけるロール。固有の振る舞いがあればそれを金額等に注入してもいいけど、そこまでする必要もないと思う。 2019-10-12 19:02:15
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌
neue cc - UnitGenerator - C# 9.0 SourceGeneratorによるValueObjectパターンの自動実装とSourceGenerator実装Tips
DDD に入門するなら、まずは ValueObject だけでもいいんじゃない？ - Qiita