ドメイン駆動開発_フォルダー構成編_#42_オブジェクト指向の自動化

オブジェクト指向的にプログラミングしましょうといっても，どういう状態がそうなのか難しいし，抽象的すぎます。そこにはある一定のルールや見本が必要です。

そもそもオブジェクト指向という概念が技術者ごとに異なるので，どのような実装がオブジェクト指向的かという意識を合わせるのが大変です。

そこで，私はこのドメイン駆動開発のドメインパターンを使って，どのような考え方にすれば，技術者ごとのばらつきがなく，自動的にクラス分けができて，だれが作っても同じになる実装方法がないかを考えました。現状次のようになるのが一番，安定して，統一したクラス分けができて，非常にオブジェクト指向的にコーディングができると思っています。

ValueObjectはデータベースの列

まず，データベースのテーブルの列をValueObjectにします。基本的に１つの列を１つのValueObjectにします。異なるテーブルでも，列名が同じ場合は同じValueObjectとして，1つだけ作ります。列名が同じなのに，ビジネスロジックが異なるというものはDB設計の時点でなくします。列名が同じということは，同じビジネスロジックにします。

ValueObjectは複数の項目で成り立つこともありますが，機械的に行うなら，データベースの列を全部ValueObjectにしてしまえば，技術者のレベルの差がなく，全体がオブジェクト指向的なプログラムになります。

Entityはデータベースの行

データベースからSelectしてきた1行のデータを１つのEntityにします。そのEntityの中のプロパティ項目はValueObjectになるようにします。

Entityをデータベースの1行を表現するようにすれば，機械的にEntityを作成することができます。つまり，データベースのSelect文で取得する項目の集まりがEntity，その各項目がValueObjectとすれば簡単にオブジェクト指向的プログラミングになります。

Entityの入れ物以外の使い方

Entityをただの値を運ぶ入れ物だけにするのは，非常にもったいないです。Entityの中にある項目同士でのビジネスロジックはEntityに入れます。例えば「MeasureDateがシステム日時の7日以内で，MeasureValueの値が０より大きい時は有効にする」などという複合的な項目で成り立つビジネスロジックを書く場所とします。

また，ToCsvDataなど，Entityを別のクラスにコンバートするような場合も，Entityに記載すればいいでしょう。

外部接触はRepository

アプリケーションの外側と接触する場合はRepository経由で取得するようにします。データベースやファイル，PC間通信など，外部から値を取得する場合，外部に値を送る場合はすべてRepositoryを挟みます。

この3つのパターンの組み合わせで，技術者のレベルに関係なく，アプリケーションの85%くらいが自動的にオブジェクト指向的プログラミングになっていき，技術者の力量に関係なく，自動的にクラス分けが行われていきます。