IODAアーキテクチャ

ザックリとした説明はこれを読めばいい。
http://www.infoq.com/jp/news/2015/06/ioda-architecture

詳細はこれ。
http://geekswithblogs.net/theArchitectsNapkin/archive/2015/04/29/the-ioda-architecture.aspx

実装例はこれ。
http://geekswithblogs.net/theArchitectsNapkin/archive/2015/05/02/ioda-architecture-by-example.aspx


上記を読んだけど、
Operation間の結合を禁止することによって、1つのクラスが肥大化することを防げるし、
Integration単位での結合を前提とすることで、
モジュールというか、機能というか、そういう特定粒度のクラス群を適切に保てるイメージがある。

Operation自体が肥大化したり、Integrationが多くなって自分でも訳わからん構造になる可能性があるが、
それらを防ぐ手段として「フロー設計」と「自己相似」がある。

フロー設計によって処理を洗い出し、クラスを切り出し、
自己相似によって、大きい粒度であろうクラス群を適切な粒度まで分解することで、
上記のOperationの肥大化とIntegration構造の複雑化を防ぐことができる。

自己相似により、
結果的に小さいIODAアーキテクチャで全体が構成されている感じになる。

他のアーキテクチャだと各レイヤのクラス群が肥大化して、
レイヤ内がグチャグチャになるケースがあると思うけど、
IODAだと自己相似によって、 それが軽減される可能性はある・・・。

とはいえ、やはり万能ではない。

Operationの肥大化、Integrationの増加を完全に防げるわけでもないし、
プロダクト投入したら何かしら問題も発生するだろう。

でも、面白いアーキテクチャだと思います。


--- 追記 2016/01/16 ---
使ったけど何か違うんだよな・・・。
あと一歩何かが足りないからフワッとした実装になっちゃうイメージ。