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基礎解説：エンティティ、値オブジェクトってなんなんだ - little hands' lab
はじめに DDDの実装パターンとして、エンティティと値オブジェクトというものがあります。 ドメイン駆動一般に複雑な抽象論が多い中で、コードに近く一番イメージがつきやすいコード事例として出てくるため、ここだけは何となくわかるぞ！という方もいらっしゃるのではないでしょうか。 今日はこちらの概要とそれぞれの使い道について書きたいと思います。 先にざっくりイメージ図をお伝えすると、こういう図を使って解説します。 何の目的で作るのか？ ドメイン駆動設計は何を解決しようとしているのか こちらの記事で、ドメイン駆動設計のアプローチは以下の2ステップがあるということを書きました。 ドメインの問題を解決するための抽象的なモデルを作る. モデルをソフトウェア(コード)に落とし込む ※ ドメイン＝ソフトウェアを適用して問題解決しようとする領域 DDDでは、このStep2の モデルをコードで表現するためのパターン
これは第2のドワンゴ Advent Calendar 2017の5日目です 5日11時時点で2日担当の yonex がまだ記事書いてないですが、気にせず続けます。niconico(く)のリリースが来年と聞いて残念な気持ちです。 おめー誰よ？ ドワンゴ Advent Calendar皆勤賞っぽいですが、私はドワンゴ社員ではありません。 定年をとうに過ぎたおじさんです。 前置き web アプリケーションの開発において、データモデリングはとても重要です。 SIerではDBAとか言って専門の設計担当がいるみたいですが、中小webサービス企業でそこまでの分業ができるわけもなく、大体においてwebアプリケーション(サーバサイド)エンジニアが担当することになります。 詳細はリンクに譲りますが、「履歴を全て残すようなデータ設計にし、 UPDATE を廃することで情報の追跡可能性を確保、堅牢な設計にする」モ
「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と
バグのないソフトウェアを作りたいお仕事では主にVB.NETとC#を。趣味のプログラミングでは関数型言語F#を利用しています。 私自身のF#スキル(関数型的な考え方)は、まだまだ実践レベルとはとても言えないシロモノだけど、 面白い発見と多くの可能性を感じられる言語なので、F#はさわっていてとても楽しい。 私はこれまでオブジェクト指向言語によるオブジェクト指向プログラミングをこよなく愛してきました。 というのも、「いかにバグを減らすか」、「バグのないソフトウェアを作ること」が私の最大の関心事だからです。 バグの多いコード、あるいは技術的負債の多いコードというのは、コスト的な問題があるばかりか、 開発者の身体や心までもを不健康にし、われわれに大きな不幸をもたらすことを経験的にわかっているからです。 わたしにとってオブジェクト指向技術は、それらの問題を防いだり解決をする手段として適した技術でした。
イミュータブルデータモデルへの取り組み with Ruby on Rails - リサーチ・アンド・イノベーション 開発者ブログ
こんにちは。リサーチ・アンド・イノベーションの中村(konk303)と申します。 いわゆる「railsおじさん」的な立場で、主にサーバーサイドの開発をしています。 Introduction 本稿ではQiitaのイミュータブルデータモデルと webアプリケーションにおける現実解にインスパイアされて、弊社でのイミュータブルデータへの取り組み(とその苦しみ)を紹介したいと思います。 qiita.com イミュータブルデータモデルとは? まるっと引用。 イミュータブルデータモデルと webアプリケーションにおける現実解 - Qiita 詳細はリンクに譲りますが、「履歴を全て残すようなデータ設計にし、 UPDATE を廃することで情報の追跡可能性を確保、堅牢な設計にする」モデリング手法です。 原則この手法に従うと、そうそう汚いモデルにはならないという優れもの(雑) です。イベントが起こる度に新規レコ
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」に「1」を足しても、「1」自身が変更される訳ではなく、新たに「2」という数字が作成されます。プログラミングでこれを表現するのが「Value Object」になります。よって、「Value Object」は不変オブジェクト（Immutable）です。Javaのプリミティブはこの数学世界の住人で、そのラッパー（やStringは）はまさに「Value Object」と言えます。どうして？オブジェクトには大きく2種類、状態が変化する「状態型」と、変化しない「値型 *1」があります。値型を実現するのが「Value Object」パターンです。状態型の方が一般的ですが、状態を持つが故に「呼び出し順序」が重要になってしまっています。そし
id:ryoasaiさんから紹介してもらったエントリで「バリューオブジェクトは不変性が本質ではない」ということを知って、「あれ？」っと思ったので、もう一度DDD本を読んで簡単にまとめてみました。 不変性は本質ではない DDD P97-98より引用 The system has to cope with all that tracking, and many possible performance optimizations are ruled out. Analytical effort is required to define meaningful identities and work out foolproof ways to track objects across distributed systems or in database storage. バリューオブジェクトがな
今日は 『ドメイン駆動設計#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」といいます この特徴の意味するところはオブジェクトをプリミティブライクに扱えることだと考えられ
3分でわかる値オブジェクト
"よくある"クラスの特徴を簡単にまとめます。 int型やDate型など、言語で用意された型を使用してフィールドが宣言されている getter/setterメソッドが実装されている このような一般的なクラスの一体何が問題なのでしょうか。 よくあるクラスの問題点 さきほど二つの特徴をあげましたが、よくあるクラスにはこれらに関連した大きな問題点があります。それは、業務アプリケーションを作り上げるために存在するクラスであるにも関わらず、「業務ルールに反した値や操作を許す構造になっている」ことです。実際のソースコードを見てみましょう。 コードで見てみる問題点 例として、先のクラスのポイント(point)というフィールドを考えることにします。仮に、「ポイントは0から1000までとすること」という業務ルールがあるとしましょう。しかし、Taskクラスにおけるポイントはint型で宣言されていますから、こんな
I searched for Value object implementation in Python, and found keleshev's implementation in github. But it doesn't provide the feature of immutability of Value object. So, I implemented property based immutable Value object class by myself. explicit property definition value based comparison, including hash Any feedbacks are welcome. ValueObject class class ValueObject(object): """ base class for
またまたValueObject、そしていよいよRoleについて
杉本啓 @sugimoto_kei 配賦計算やら外貨換算など計算処理が主題になる場合、Allocator とか CurrencyTranslator といった動詞的オブジェクトを作ることに、僕はあまり抵抗がない。配賦計算は、配賦される金額に属する訳ではないし、配賦割合に属する訳でもないと思うから。こういうのを嫌う人は多いのかな。 2019-10-12 18:57:11 杉本啓 @sugimoto_kei 配賦計算というコンテキストがあって、配賦対象金額や配賦率といった概念が生まれるのであって、その逆ではないと思うのな。DCI的に言えば配賦金額や配賦率は配賦計算というインタラクションにおけるロール。固有の振る舞いがあればそれを金額等に注入してもいいけど、そこまでする必要もないと思う。 2019-10-12 19:02:15
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
イミュータブルデータモデルと webアプリケーションにおける現実解 - Qiita
メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌
実はオブジェクト指向ってしっくりきすぎるんです！ 不変オブジェクトのすゝめ。 - Bug Catharsis
neue cc - UnitGenerator - C# 9.0 SourceGeneratorによるValueObjectパターンの自動実装とSourceGenerator実装Tips
Value Object（バリューオブジェクト） - Strategic Choice
DDDのバリューオブジェクトは不変性が本質ではない - かとじゅんの技術日誌
DDD に入門するなら、まずは ValueObject だけでもいいんじゃない？ - Qiita
ValueObject implementation in Python - Qiita