タグ別アーカイブ: DDD

アナリシスパターンを理解する

最近立ち返ってDDD本を読み進めています。
今回は11章の気づきに関して取りまとめます。

概要

第11章ではアナリシスパターンについて解説している。
本記事ではそれに対する個人的な解釈を述べる。
実際にはアナリシスパターンは非常に抽象的な話で、概念的に理解するのはそこまで難しくはない。

アナリシスパターンとは

アナリシスパターンとは既存の業界についてすでに洗礼されたモデル(それはシステムとしてという文脈とは全く関係なくて構わない)が存在する際に、そのドメインを学習することでドメイン設計に対するアプローチとすることである。

本章では具体的に会計システムの開発を行う際に、会計の専門書を解読することで設計のアプローチとする例が取り上げられている。

また外部の知識と合わせて現場にドメインエキスパートがいるようであれば、ユビキタス言語を用いて設計をすり合わせることでより洗礼されたモデルを設計することができる。

これは非常に強力な手法であり、まず率先して取り入れるべき方法だと思う。
特にその業界に対する知見が全く無い場合丸腰で設計するのは自殺行為に等しい。
システムという側面に囚われすぎず、一般的な専門書などから得られる洞察は膨大なものになるだろう。

ドメインエキスパートについて

この例ではドメインエキスパートが出てき、開発者とともに簡素なクラス図のようなものを用いている。
だが実際に現場にいるドメインエキスパートがここまで開発側の用いている手法に対して理解があることは少ないのではないかと思う。
それは協力的な姿勢であったり、そもそも開発者が用いているクラス図がどのようなもので、どういったヒントを求めているかというコンテキスト的な解釈ができるかどうかという事も含めてである。

そういう意味で、本章に出てきているドメインエキスパートを含むチームはすでにチームビルディングに巧みに成功している例といえ、自分の経験上現実にこのような状況になることは難しい。

チーム全体がDDDを理解しているためには組織全体が積極的に働きかけ、エンジニアだけでなく広い範囲でこうした開発スキームの理解をし、さらに時間をかけて学習している必要がある。

否定的な意見を言ったが、現実的にはクラス図などを用いなくとも、ドメインエキスパートから話を聞くということだけでも大いに有益であり、これも積極的に取り入れることで恩恵に預かれる。

アナリシスパターンの肝

個人的に「業界知識」「ドメイン設計」「実装」この3つのバランスを上手く取ることがアナリシスパターンの肝だと感じる。
まず「業界知識」「ドメイン設計」の部分であるがこの2つは実際に最終的に落とし込む場合に異なる箇所が出てくる。当然全く同じ状態になるかとそうでもない。
アプリケーションを実現するということが第一目的であるため、独自の知識や組み合わせなどが出てくることがあるからである。
適切な境界やモデルが出来上がるまでに何度も設計を吟味してドメインを練り直す必要がある。この際に業界知識に引っ張られすぎてはいけない。

また「ドメイン設計」「実装」に関しては実装が持つルールやフレームワークを使用している場合、また言語の特性によってはドメイン設計をそのまま実装に落とし込むことが困難になる場合がある。
そのためドメイン設計を多少捻じ曲げて実装を行うこともある。
この際なぜそうなっているのかという証拠などを十分に残して置くことなどが大切になるのではないかと思う。


MVCというデザインパターンはもはや十分ではない

概要

今さら私が提示するような話でもないほど同じような話はネット上に腐るほど存在しているだろう。
にも関わらず不思議とシステム開発の現場レベルで見てみると、昔と変わらない手法をずっと続けていたり、また優秀なアーキテクトに恵まれていない現場などはひどく絡みあったコードと格闘していることは多い。
改めて近代的なデザインパターン・アーキテクチャとは何かということについて自分なりに詰めてみようと思う。

初めてに言ってしまうと、ずばりこの記事の着地は ドメイン駆動設計(DDD)への招待である。
同じような疑問を感じている人の何かヒントになればと思う。

人々はオブジェクト指向を手にした

昨今のソフトウェア製作の設計パターンは変化しているのだろうか、ということをまず考えてみよう。
「コンピュータの登場から今まで」のような大きなくくりで見た時には、ソフトウェアの設計パターンは大きく変化していると断言していいだろう。(といってもそんな昔に私は生まれていないが)

時代ごとに変化する大きな要因の一つに、偉大な先人たちが開発してきたコンピュータ言語がある。
昔はアセンブラ・C言語などの、手続き型言語が大部分を占めていた時代があるが、この頃開発においてドメインに着目するというよりかは手続きそれ自体に着目している。
これは言語のパラダイム的にやむを得ない部分が大きいが、いずれにしてもプログラミングされたその内容はそれぞれが意味をあまり持たない。個別には意味がわからない処理の連続が、結果として業務ロジックとして存在している。

その後時代は流れてついに人類はオブジェクト指向言語を手にする。このオブジェクト指向というのはプログラミングパラダイムの革命の一つと言っていいだろう。
オブジェクト指向によってドメインモデルと実装がかなり親和性を持って結合できるようになったのである。
そしてコンピュータ資源も豊富になってきた今、高級言語を使っていればあまりメモリなどの資源を期にすることもない。
実装都合でねじ曲げてきた手続き型への束縛からも開放されつつある。

これが爆発的となり、様々なツールなどが世にでる。sbtなどのマルチプロジェクトを取り替えるような機構ができたりして、その実装性能よりも、実装とドメインモデルをどれだけ近づけて、人間の脳に理解しやすいようにプログラミングを行う時代になっている。

MVCの誕生

Web業界ではそれまで多くのシステムは cgi と呼ばれる仕組みを利用してシステムを実装していた。
これは先程の話で言うとオブジェクト指向の誕生前で、割りかし手続き型の側面が強かった。

これがオブジェクト指向の出現によってMVCというデザインパターンの実装が用意になり、それをサポートする多くのフレームワークが誕生した。
多くの(初級)開発者たちはとりあえずMVCすればそれなりに構造化された実装を手にすることができた。

MVCの功として、まず多くの初級開発者たちにとって開発の目印になってくれたことである。
それまでとくらべてエンジニアたちの一種のヒントのようなトピックを投下して議論の対象となった。

また実際そのデザインパターンはシステムがあまり大きくないうちは非常に効率的に開発できる(ように見える)ためそれほど規模の大きくないシステムにとっては問題がそれほど露呈しない場合も多い。

MVCは銀の弾丸ではない

実際MVCのすべてが否定されるべきものではない、一種のアンチパターンとして利口なUIパターンなどというものがあるがそういった多くの場合はとらないでおくべき選択肢を序盤に排除してくれるような働きをしている。

ただ単純にMVCという一言で対応するにはシステム開発はそれほどシンプルではなかったという話である。

個人的に思うところは MVC の表す Model の責務が大きすぎるのである。
そのため人によって解釈が異なったり、またそもそもそこの設計を怠ったりということで大きなシステムに対応できなくなっているパターンをよく目にするように思う。

具体的によく目にするのが Model 内部にDBレイヤへのアクセス処理などが記述されていて、どんどんモデルが膨らんでいくなどのようなことである。

本来のクラスの責務をしっかり検討する必要があり、MVC を拡張するようなよりドメインとマッチした設計思想が必要なのである。

DDDへの招待

そこで DDD である。昔からあったのかもしれないが、最近特に多く目にするようになってきた。

DDD とはドメイン駆動設計の略称であるが、これはドメイン(業務ロジック)に特に着目して、それをいかに齟齬なく実装に落としこむかということに着目した設計手法である。

実際かなり具体的な設計思想を(先人たちの経験の蓄積として)もっており、これらを盛り込むことでシステムが大きくなってきた際にも拡張性がある実装を担保できる。

たとえば具体的には先程の話で一緒くたに Model と称していたものを Entity や ValueObject など(他にもいろいろあるが)いうようなより詳細なドメインモデルに落としこむ。
これによりMVCで取り扱っていたものを、より適切な責務へと分割することができる、、、などなど

その内容については長くなるのでまたの機会に割愛するが、DDDのバイブルである下記の書籍に目を通すと良いと思う。一度目を通しておいて損はないです。