再利用(Reuse)はこの13年間，システム開発のほぼすべての事象に対するモットーだった。しかしながら再利用は，少なければ健康的だが，度が過ぎるとダメージを被る，シアン化合物のようなものだ – ロンドンで開催された今年のDDD Exchangeカンファレンスでのプレゼンテーションで，Udi Dahan氏はこのように述べて，ビジネスロジックの面からの視点を提案した。
SOAとDDDのオーソリティであるDahan氏は，オブジェクト指向が普及する過程において再利用が重要な役割を果たしたことは認めながらも，それが階層構造の際限ない利用による混乱と強く結び付いている点を指摘した。そしてその後5～10年，コンポーネント指向の台頭により，コンポーネントの再利用に大きな期待が寄せられたのだが，その時も再利用が私たちを救うことはなかった。そして今はSOAが，さらにはマイクロサービスが出現して，再利用性を強調している。これら過去の経験すべてから，Dahan氏は疑問を呈する – これまでうまくいかなかった再利用が，果たして今回はうまくいくのだろうか？
再利用を誤りだとする考え方は，何も今始まったものではない。Dahan氏は，Ted Neward氏と，同氏が結論としてエンタープライズコンピューティングの誤謬に加えた“ビジネスロジックは集中可能であり，そうあるべきだ”という項目を紹介した。ここでDahan氏は，ある単純なルールを取り上げる - 名前は40文字未満にしなければならない，というルールだ。このルールはどこに適用すべきだろう？一般的にこのようなルールは，UIやビジネスロジック，データベースなどで実施されている。しかしいくつかの実装では，そのルールを変更しなければならない場合に問題が発生する。Dahan氏の経験したソリューションのひとつは，メタデータからのコード生成，すなわちルールは一箇所で変更可能にしておいて，すべてのコードをそこから生成する，というものだ。しかし氏の経験では，この方法はいつも失敗している。根本的な問題は，ルールが複数の場所で適用されていることではなく，変更可能な場所をすべて見つけ出すのが困難なことにある。Dahan氏の提案するソリューションはソースコントロールの利用だ。ルールをイシューとして保持しておいて，そのルールに対処したすべてのコードを，イシューにリンクした１回のコミットにしておくのだ。こうしておけば，そのルールを適用したすべてのコードを簡単に見つけ出すことができる。
ルールが変わったら，ソースコントロールの指示に従うのです。
アーキテクチャは，単純な図で描けるような２次元的な問題ではない。Dahan氏は， アーキテクチャを単一のビューにまとめるのは不可能であるとするPhilippe Kructhen氏の4+1アーキテクチャビューモデルを紹介した。全体的な複雑さに対処するためには，さまざまな視点をカプセル化したビューが必要なのだ。Dahan氏がマイクロサービスの問題点とするのは，すべてが同じビュー，開発単位，ロジック，プロセスであることに加えて，サービスに対して過大な制約を課していると氏が考える，ひとつのビューに落とし込まれている点だ。
マイクロサービスに向いているとDahan氏が考えるシナリオのひとつは，新たなビジネスケースをテストするために，間に合わせでよいので個別にデプロイ可能な実装が必要な場合だ。ただし重要なのは，作業が終了したら書き直しを行うことである。この点について，前もって同意を得ておくことが必要だ。
Dahan氏は昨年末にも，企業のマイクロサービス導入に対して批判的な意見を述べていた。
来年のDDD Exchangeは2016年6月10日の予定で，すでに登録を開始している。