2016年1月26日デジタルとアナログ。2016年1月12日2016年あけましておめでとうございます。以前ご紹介した通り、ギルドワークスではドメイン駆動設計(DDD)の勉強会を社内で行っています。その中で出てきた指摘に、ハッとする物があったので、今回はそれについて、ご紹介します。「それ、ソースコードに書いてないじゃん」それは、DDDを前提においたコードレビューで飛び出した指摘でした。コードはかなりシンプルな、ユーザからの投稿とそれに関する感想を閲覧する、といったサービスに関するものでした。いった場合、当然のように、『”投稿”がトップレベルのオブジェクトにあり、それにぶら下がる形で”感想”オブジェクトがある』という様なモデル化をしていました。このドメインにおいては、投稿もさることながら、投稿に対する感想の方がドメインにおける重要な関心事、なのでした。実装に構造を語らせるためにこの時、僕は軽く衝撃を受けました。「だって、ソースコード見てそのドメインの関心事が分からなければ、3年後見た時にわかると思う?」...はい、分かりませんよね。エヴァンスのDDD本に書いてあった、以下の一節は、そういうことを言っています。ある種の意思決定をすることによって、モデルと実装の協調が保たれ、互いがもう一方の効果を高めるようになる。第二章の導入よりモデルと実装が、協調している。モデル通りの実装になっているし、実装からモデルがわかる。そのモデルというのは、ただの設計構造ではなく、顧客の関心ごとを反映した「ドメイン」である、ということ。すればいいのか?「それに答えなんかないですよ。実験してみることです。確かに、ソースコードで物を語るには、クラスの所有関係を表すのが一番です。なんとなく、理屈で収まりがいいツリー構造を考えてしまいますが、勇気を持って構造を組み替えたりして、色々実験しなければなりません。確かに、DDDではリポジトリという形で、永続化処理をドメインから分離しています。することで、永続化層の理屈をドメインから分離し、ドメインの中で腹落ちするようなモデルを構築していくのですね。ドメインの設計を、ソフトウェアシステムにおけるその他の大量の関心事から分離することで、設計とモデルとのつながりが非常に明確になる。第二章の導入よりと、偉そうなことを書いていますが、私もまだまだ勉強中の身。これからも色々と実験を重ねていきたいと思います。ギルドワークスでは、こうやってドメインのあるべき構造を追い求めてくれるような、ギルドメンバーを引き続き募集中です!興味を持たれた方は、こちらからどうぞ。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。