SLAP(Single Level of Abstraction Principle : 抽象化レベル統一の原則)

DDDに使えそうなのでメモ。

この考え方を知ったのは「プロダクティブ・プログラマ」の13章から。

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

細かい解説はIBM developerworksの 「進化するアーキテクチャーと新方式の設計: Composed Method と SLAP」がほぼこの本と同じコンセプトの解説をしているのでそちらを・・・

SLAPはざっくり言うと、以下のようなものを分離するための考え方

  • DB接続を管理するような下位レベルの詳細
  • ビジネス・アナリストが理解するような上位レベルのメソッド

一方、Domain Driven Design(DDD)では「Making Implicit Concepts Explicit(暗黙的な概念を明確化する)」という章がある。

ここでは、以下の記述があります。(P205)

Many transformations of domain models and the corresponding code happen when developers recognize a concept that has been hinted at in disscussion or present implicitly in design,and they then represent in explicitly in the model with one or more objects or relationship

概念が議論で示唆されたり設計の中に暗黙的に現れたりしたと開発者が認識すると,ドメインモデルと対応するコードに多くの変化が生じ,一つ以上のオブジェクトまたは関連としてモデルの中に明確に表現されます.

DDD/Chapter Nine. Making Implicit Concepts Explicit - Java EE勉強会

そして、以下の記述(P223)

The key to distinguish a process that ought to be made explicit from one that should be hidden is simple:Is this something the domain experts talk about,or is it just part of the mechanism of the computer programs?

隠すべきプロセスから明確にするべきプロセスを区別するのは簡単で、それが、ドメインのエキスパートが話したことか、コンピュータプログラム上のメカニズムの一部なのかで決まる。

DDD/Processes as Domain Objects - Java EE勉強会

これって、SLAPをうまく使えばできそうだよね!