「DDD」の記事 - Crieit

C# の DateTime で説明する ValueObject

2020-10-28T00:50:39+09:00

ValueObject イズ何？

ValueObject とは「何らかの概念についての状態と振る舞いを持ち、その概念の責務を果たすオブジェクト」です。
ValueObject はそれが定義される上で満たすべきいくつかの要件があります。
IDDD 本で示されている ValueObject が満たすべき要件を確認してみたいと思います。

No.	要件	説明
1	計測・定量化・説明	そのドメイン内の何かを計測したり定量化したり、あるいは説明したりする。
2	不変	状態を不変に保つことができる。
3	概念的な統一体	関連する属性を不可欠な単位として組み合わせることで、概念的な統一体を形成する。
4	交換可能性	計測値や説明が変わったときには、全体を完全に置き換えられる。
5	値の等価性	値が等しいかどうかを、他と比較できる。
6	副作用のない振る舞い	協力関係にあるその他の概念に、副作用のない振る舞いを提供する。

引用 : ヴァーン・ヴァーノン. 実践ドメイン駆動設計

どうでしょう、初見で理解出来ましたか？
「全然わからん」となったそこのあなた。もしあなたが C#er なら ValueObject は怖くありません。
あなたは既に ValueObject を知っているからです。

人間誰しも自分の理解していない事柄に対しては拒絶感を抱きやすいものですが「既に知っている」となればどうでしょうか。
この記事は「まだ ValueObject をあまり知らない方」に向けた「ValueObject に対する拒絶感を和らげる」ために書かれた記事です。

DateTime で説明する ValueObject

C# には日時を取り扱うための構造体として DateTime があります。C#に触れたことがある人ならば一度は見たことがあるのではないでしょうか。
この DateTime ですが実はある種の ValueObject です。
嘘ではありません。
それでは DateTime で ValueObject の要件を説明していきましょう。

計測・定量化・説明

言わずもがな DateTime は日時を示す為の構造体です。
日時に関しておおよそ一般的な定義や振る舞いを提供してくれます。

不変

DateTime は読み取り専用構造体として定義されておりインスタンス生成後に状態を変更することは出来ません。
「状態を不変に保つことができる」と言うより「状態が不変であることを強制されている」と言う方が正しいかもしれません。

    public readonly partial struct DateTime : IComparable, IFormattable, IConvertible, IComparable, IEquatable, ISerializable, ISpanFormattable

引用 : .NET Core Source Browser DateTime.cs

既に存在する DateTime インスタンスとは別の日時が欲しい場合は常に新しいインスタンスとして生成されます。
一例として AddDays メソッドの定義を見てみます。

        public DateTime AddDays (double value);

引用 : DateTime.AddDays(Double) メソッド | Microsoft Docs

戻り値が DateTime になっていますが、この戻り値について MS Docs の説明にはこう書いてあります。

このインスタンスの値に、指定された日数を加算した新しい DateTime を返します。

引用 : DateTime.AddDays(Double) メソッド | Microsoft Docs

上記の通り新しいインスタンスを返却します。自身の状態を変更して自身の参照を返す訳ではありません。
AddMonths メソッドや AddYears メソッドも同様です。

概念的な統一体

ここに「2000」という数字があるとします。この数字は、これだけでは殆ど価値のある意味を持ちません。
ですが「年」という言葉と組み合わせると「2000 年」になり、只の「2000」よりも具体的な意味を示すようになります。

DateTime には「年」以外にも構成要素があります。
月、日、時刻、現地時間なのか UTC なのか、などです。
これらの属性が組み合わせることで「現地時間 2000 年 4 月 1 日 12:00」の様な日時として更に意味のある概念を示せるようになります。

この様に複数の属性で何かを説明したり意味のある概念を示すものが「概念的な統一体」です。

交換可能性

DateTime は「不変」であるため、交換が不可能であると値を変更することが出来なくなってしまいます。
その為 DateTime は交換可能でなければなりません。

            // dateA に「2000 年 1 月 1 日」のインスタンスをセットしたあと 「2000 年 1 月 2 日」のインスタンスに「交換」する。
            var dateA = new DateTime(2000, 1, 1);
            dateA = new DateTime(2000, 1, 2);

C# 的には当たり前のことかもしれませんが ValueObject として必要な要件です。

値の等価性

C# において等価性について何も考慮されていないクラス／構造体では、内部で保持している値が同じだとしても異なるインスタンス同士は等価と判断されません。

        // 参照型のクラス
        public sealed class User
        {
            public User(string id)
            {
                this.Id = id;
            }

            public string Id { get; }
        }

        public void Main()
        {
            var userA001 = new User("1234");
            var userA002 = new User("1234");

            // 同じ ID なので等価として判断して欲しい。
            if(userA001 == userA002)
            {
                Console.WriteLine("同一ユーザー"); // しかし出力されない。
                return;
            }

            Console.WriteLine("別ユーザー"); // 出力される。
        }

ですが同じ値を保持しているのであればそれらのインスタンス同士を等価として判断して欲しい場面があります。
C# にはそんな時の為に異なるインスタンス同士の等価性判断を提供する IEquatable インターフェースや == 演算子が用意されており、DateTime でもこれらが実装されています。

        public static bool operator ==(DateTime d1, DateTime d2) => d1.InternalTicks == d2.InternalTicks;

引用 : .NET Core Source Browser DateTime.cs

これにより DateTime では異なるインスタンス同士を違和感なく等価かどうか判断出来るようになっています。

            var dateA = new DateTime(2000, 1, 1);
            var dateB = new DateTime(2000, 1, 1);
            Assert.IsTrue(dateA == dateB);

この様に等価かどうかを判断出来ることが「値の等価性」です。

副作用のない振る舞い

「副作用のない振る舞い」とは何かを出力するけれども自身の状態は変更しないものです。
引用 : ヴァーン・ヴァーノン. 実践ドメイン駆動設計

「不変」の要件と異なるのは「何かを出力するけれども」という点です。
DateTime がただ「不変」であるだけで良いのであれば AddDays メソッドや AddMonths メソッドは不要な筈です。
異なる日時のインスタンスは全てコンストラクタで生成すれば済むからです。

しかし新しいインスタンスが欲しくなる度にコンストラクタを呼び出していてはコードが冗長になる上にバグを埋め込む可能性も高くなります。

            var dateA = new DateTime(2000, 1, 31);
            // dateA の翌日が欲しかったが 31 日であることに気付かず日付に 1 を足してしまった。
            var dateB = new DateTime(dateA.Year, dateA.Month, dateA.Day + 1);

こういったことを防ぐ為に DateTime では AddDays などのメソッドを提供しています。
この様に『その概念に関する振る舞いをカプセル化して「不変」であることを保ちつつ何らかの値を返却する』ことが「副作用のない振る舞い」です。

DateTime は ValueObject

無事に DateTime で ValueObject の要件を全て説明することが出来ました。
同時に DateTime は ValueObject としての要件を満たしていることが分かりました。
「ValueObject 全然わからん」という方でも「つまり DateTime みたいなヤツだな」という理解が出来るようになったのではないでしょうか。

おまけ : ValueObject のポイント

ValueObject 6 個の要件は以下の様に 3 つのグループに分けることが出来ます。

概念
- 計測・定量化・説明
- 概念的な統一体
不変
- 不変
- 交換可能性
- 副作用のない振る舞い
等価性
- 値の等価性

概念グループの 2 つの要件は両方とも ValueObject で何らかの概念を定義する為の要件なので同じグループです。

不変グループは ValueObject が「不変」であることが前提にあり、残りの 2 つは「不変」であるが故に生じる要件なので同じグループです。
「不変」であろうとすると自然に「交換可能性」と「副作用のない振る舞い」を満たす実装になります。

等価性グループは「値の等価性」だけのグループです。

自分で ValueObject を定義する際は「概念（のカプセル化）」、「不変」、「等価性」の 3 点を意識しておけば良いと思います。

やはり俺のDDDの理解は間違いだらけ

2019-08-26T12:34:25+09:00

「ポエム」タグをつければ何を書いてもいいと許されると思ってるし、書きかけでも許されると思ってる。

なんでDDDやることになったのか

なんでだっけ？

なんか前に居た会社でも「クリーンアーキテクチャで作られているプログラムだから、ソースコードを改変せずにAPIから上手にビジネスロジックを剥がしてドメインを叩ける」
というどちゃクソ理論押し付けられていい経験はしていないのだが。

とはいえ、最近CSharpでアプリを作ると、テンプレートがそんな感じの作りをしているからだったかもしれない。

ASP.net MVC5だと

データアノテーションを付け加えることができるから、値オブジェクトとかエンティティを作る必要がない可能性がと思ったが、完全に勘違いだと思った。説明はうまくできない。

using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace Ultra.Hyper.Models
{
    [Table("m_users")]
    public class User
    {
        /* アノテーションをつけると入力されるデータの制限とかができるだろうけど */ 
        [Key]
        [Column("id")]
        [StringLength(5)]
        public string ID { get; set; }

        /* こういう実装の方が丁寧に思うぞ */
        [Key]
        [Column("id")]
        {StringLenth(5)]
        public IDentityNumber { get; set; }

        // :
        // :

        [Column("name")]
        [StringLength(128)]
        public string Name { get; set; }

        /* 性別が特にそんな気がする。
           これより：*/
        [Column("sex")]
        [StringLength(2)]
        public string Sex { get; set; }

        /* こっちの方がいい気がする（Sexクラスの実際の実装は省く） */
        [Column("sex")]
        [StringLength(2)]
        public Sex Sex { get; set; }
    }
}

と、思いつきコードを書いたが、データアノテーションってあくまで「入力されたデータに対して」だと思ったので、リポジトリ群に書くものではないのではと思った。

だから、データベースの設計とプログラムの設計はまた別の話になるだろうし、ましてや自分が自由にやって許されているのはプログラムの設計までなので、データベースのテーブル構造とリポジトリのクラスが一対のものになるかというと、別問題じゃないかなと。

それに、レイヤードアーキテクチャの依存関係を考えた際に、外から内側への依存は良いとして、内側から外側への依存しちゃうとダメだと言う記憶。

なので、データの永続化に関しても、ドメイン部分にSQLを書いてDBへの書き込み処理を書くのは完全に間違ってる。と思う。

ということで、データアノテーションを書くべきは、フォームなどのビューからデータを受けるモデルに対して行うべきであり、データ永続化処理（リポジトリとか）に書くのは違う気がしてる。

ヤマもないしオチもない。続きが合ったら加筆するかなあ？

参考資料

多すぎるのでまた後で加筆すると思うぞ。

書籍

実践ドメイン駆動設計
Clean Architecture

2019-08-27 追記

プロジェクトリーダーさんから頂いてるDBレイアウトを元に、どんなデータが必要かを何となくモデリング（？）したが、未だにエンティティとサービスと集約をどの辺りで切り分けるべきなのかよくわからない。

業務ロジックが見えたら、多分この辺の切り分けができるのだが。

PlantUMLで書いたクラス図を、何となくオニオンアーキテクチャにはめてみるとそれっぽい感じにはなるが、ドメインモデル層の中で、エンティティが複数の値オブジェクトに絡んでいたり、更にエンティティが他のエンティティを参照していたりして、正しいのか全く自信が持てない。

2019-09-30 追記

先日たまたまCoderDojoのメンター仲間さんとコワーキングスペースで出会って、話の流れでDDDの事を話したが、結局、
「ゑ、それってオブジェクト指向で実装すれば自然とそうなるものじゃないの？」
という返答をいただいて、自分はやっぱりDDDの事を理解していないのだなと改めて感じた。

その時のDDDの説明：

例えば個人情報に持たせたいデータは、性別・住所・連絡先などとありますが、それらを一つのクラスにまとめて実装するのではなくて、ちゃんと「性別クラス」「住所クラス」「連絡先クラス」と分けて実装するんです。そうすると、個人情報の性別に関する編集だけなのに、編集するコードの量が必要以上に多くなることがない、つまり、編集者は編集する事柄に集中できる設計方法なんです。

改めて書き出したが、やはりこの説明では、そりゃあ、
「オブジェクト指向で組めばしぜんとそうなるじゃん」
と言われるわ。

ボトムアップDDDを写経した

2018-09-29T18:37:56+09:00

まえがき

最近、通勤の合間などにIDDDを読んで少しづつDDDの知識を取り入れている。ユビキタス言語や境界づけられたコンテキストなど、概念的な定義が個人的に難しくて読むのに時間がかかっている。

そんな時にnrsさんのブログに書かれている、ボトムアップドメイン駆動設計を読んだ。理解や実践が難しい箇所はひとまず置いておき、理解しやすく実践しやすい箇所からまず始めてみようという内容だ。

自分にぴったりだと思って一通り読んだ後、せっかくなのでPHPとLaravelを使って写経をしてみた。一通り書いてみた感想としては、OOPの特性を活かしたコーディングとはこういうことなんだなとふんわり掴め、責務の所在が明確だとファイルが増えても処理が追いやすいなと感じた。

参考にした記事で扱われているものは次の5つ。どれも技術的な要素なので、普段コードを書いている人にとっては読みやすいと思う。

値オブジェクト
エンティティ
ドメインサービス
リポジトリ
アプリケーションサービス

また、サンプルとは異なる実装をしている箇所を以下で補足する。

変更点

コンストラクタ

PHPは__construct()を複数定義出来ない。そのため、今回はデフォルト引数を用いて実装を行った。

id = $id === null ? new UserId(Util::guid()) : $id;
        $this->userName = $userName;
        $this->fullName = $fullName;
    }

    // 以下の処理は省略...
}

ただ、必ず引数で受け取る$userNameと$fullNameを引数としたコンストラクタを定義し、2つの引数に合わせて$idと3つを引数に受け取る静的メソッドを定義すれば擬似的に複数定義することも出来なくはない。

id = new UserId(Util::guid());
        $this->userName = $userName;
        $this->fullName = $fullName;
    }

    public static function ctorWithId(
        UserName $userName,
        FullName $fullName,
        UserId $id
    ) {
        $instance = new self($userName, $fullName);
        $instance->id = $id;
        return $instance;
    }

    // 以下の処理は省略...
}

個人的な意見としては、生成処理のパターンが増えたり、複雑であればファクトリを用意すれば良いのかなという解釈でいる。

等価性の判定

C#やJavaのObjectクラスにはequals()というメソッドが定義されており、等価の判別が出来る。これもPHPには用意されていないので、汎用的なメソッドとして用意し、インターフェースを実装した。





リポジトリ

Laravelを使用したということもあり、学習も兼ねてEloquentを用いて実装した。

userEloquent = $userEloquent;
    }

    /**
     * @param UserId $userId
     * @return User|null
     */
    public function findByUserId(UserId $userId)
    {
        $target = $this->userEloquent->find($userId->value());

        if ($target === null) {
            return null;
        }

        return new User(
            new UserName($target->user_name),
            new FullName($target->first_name, $target->family_name),
            $userId
        );
    }

    /**
     * @param UserName $userName
     * @return User|null
     */
    public function findByUserName(UserName $userName)
    {
        $target = $this->userEloquent->findByUserName($userName);

        return $target;
    }

    /**
     * @return User[]
     */
    public function findAll()
    {
        $users = $this->userEloquent
            ->all()
            ->map(function (UserEloquent $userEloquent) {
                return new User(
                    new UserName($userEloquent->user_name),
                    new FullName(
                        $userEloquent->first_name,
                        $userEloquent->family_name
                    ),
                    new UserId($userEloquent->id)
                );
            })->toArray();

        return $users;
    }

    public function save(User $user)
    {
        $this->userEloquent->persist($user);
    }

    public function delete(UserId $userId)
    {
        $this->userEloquent->deleteByUserId($userId);
    }
}


あとがき

正直なところ、読む前はリポジトリやエンティティを用いてDDDしてみたというような記事をみかけては、「それって〇〇アーキテクチャを適用しただけでは…？」と思っていた。でも実際書いてみると、かなり歯ごたえがあって実装したときの達成感のようなものがあったので、書きたくなるのもわかるなぁという感じ。こうして自分も記事にしているので。

ただ参考記事や書籍にも書かれているように、ユビキタス言語や境界づけられたコンテキストなどの概念がより重要であり、技術的な側面だけを注力するといわゆる軽量DDDに陥ってしまうので、戦略的設計に関わる知識もインプットしていく。


  軽量DDDとは、DDDの戦術的パターンの一部だけをつまみ食いする方法で、ユビキタス言語を見つけ出して育てていこうなどという気は毛頭ない。おまけにこの手法は、境界づけられたコンテキストやコンテキストマッピングも使わずに済ませることが多い。技術面だけに注目して、技術的な問題だけを解決したがっているのだ。この方法にはメリットもあるが、戦略的モデリングを併用したときのような大きな見返りは得られない。（実践ドメイン駆動設計より）


最後に写経したものはGitHubに置いているので、参考になれば。

[https://github.com/chocol4t/bottom-up-ddd-php:embed]

nrsさんのサンプルコードはこちら。(C#)

[https://github.com/nrslib/BottomUpDDD:embed]

参考URL


ytake/valueobjects


Utilクラスを参考にしました。