形が見え始めたファイルマネージャですが、毎回ここまでは辿りつくのですが、この後が中々難しい。
WPFの画像オブジェクトを扱うために、wpflibでプロジェクトを追加して、WPFAppプロジェクトから画像加工ルーチンを移動させました。
画像を読み込んでデコードして、DPIを調整するぐらいの加工ですので、基本staticのHelperクラス扱いで良さそうです。
画像関係は今のところそれで良さそうですが、ファイルマネージャのバックエンドはファイルシステムのアクセス部分に成ります。この部分を再利用できるように<abbr=”ドメイン駆動設計”>DDDのエッセンスを取り入れたいと思います。今回のファイルマネージャ作成に挫折しても次に生かすための保険みたいなものです。
とりあえずDDDの書籍を読んでみましたが、まったく頭に入ってくる感じがしないので、サンプルコードから実装部分をエッセンスとして頂くことにします。DDDは考え方ですので実装方法は無数にあるとは思いますが、考え方が理解できなくとも実装をまねれば恩恵が得られるのでは無いかと考えます。
大きくドメイン層とインフラ層に分かれていて、ドメイン層にEntityがあり、管理するオブジェクトを定義しているようです。
再利用することを考えると、特別な属性を持たないPOCOなクラスで、データの保持を目的と考えると、プロパティで構成すると都合が良さそうです。
インフラ層は具体的な振る舞いを扱い、具体的にはデータベースのアクセスやファイルシステムの読み書き、ネットワーク通信などが相当すると考えます。メソッドが中心になると思いますが、結果はドメイン層のEntityクラスのインスタンスとして返すケースが多い模様。
インフラ層はドメイン層のEntityを扱いますので、当然ドメイン層を知っています。逆にドメイン層はインフラ層を知りません。具体的なインフラ層の実装は知る必要な無いですが、インフラ層でEntityがどのように扱われるかを定義しておく為に、Repositoryがあります。
一見何の目的があるか不明ですが、Repositoryをinterfaceとすることで、実装を知らない外部から、インフラ層の機能を扱うことが出来ます。これの何が嬉しいかと言いますと、Repositoryはあくまでinterfaceの器とかんがえて、中身となる実装を差し替えることができます。本番環境とテスト環境の切り替え、異なるデータベースへ移行などが考えられます。恩恵が受けられるかどうかは別としても適用しておいて損が無さそうです。
あと書籍にはValueObjectというオブジェクトの説明もありました。一見するとconstがコンパイル時に決定する「静的な定数」に対して、値は動的に決まるが解放されるまで不変であることが保証される、「動的な定数」といった感じです。器は変数ですが、初期化はするが変更は出来ない性質に成ります。具体的にはメールアドレスは文字列ですが、その書式は固有のルール（入力規則）があります。メールアドレスを入力する場合、入力規則にもとにバリデーションを行うと思いますが、ValueObjectクラスに入力規則の情報を持たせると、集約されることで、機能が散らばることが避けられますし、再利用する場合でもメリットが大きいです。
値が変更できない点は不自由な感じがしますが、値を変更する場合新しいオブジェクトを作れ、ということだと考えると、同じ変数を使いまわすよりトラブルが減ると思います。
といった感じの理解で、書籍のサンプルコードをなぞる感じで進めたいと思います。
20250605
ドメイン層のEntiyとRepositoryとインフラ層にコードをリファクタリングしてみました。
あとはValueObjectを適用するところですが、ValueObjectに出来るのは変更不可のオブジェクトで有る点と、変更ではなく新しいオブジェクトを作ることを考えると、使い方を学ぶ必要がありそう。
コメント