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

なんで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の説明：

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

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