ザックリとした説明はこれを読めばいい。
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 ---
使ったけど何か違うんだよな・・・。
あと一歩何かが足りないからフワッとした実装になっちゃうイメージ。
