注）これは、自分なりの理解です。
ICONIXとは（ざっくりとした説明）
設計手法。
詳細なユースケースを記述することで、設計を駆動する。
ロバストネス分析を行うことでユースケースの具体化が可能になる。
オブジェクト指向的でドメイン駆動的な設計が可能になる。
予め詳細な設計を行うことで実装段階での予期せぬ考慮漏れが減り、手戻りが減る。
またより正確な工数の見積もりが可能になる。
ICONIXプロセス
ドメインモデル作成
ある程度要件がまとまった段階で、ユースケースを書く前に、ドメイン分析を行う。
ドメイン分析を行わずにユースケースを書いてしまうと、曖昧な表現を許してしまう。
ここでは単に各ドメインオブジェクトの関連を描くだけに留めておき、
多重度や属性などは考えない。
Has関係かIs関係でほとんど全ての関係性が表現できる。
Has関係
Is関係
ユースケース記述
ドメイン分析で洗い出されたオブジェクトの名詞を用いて、ユースケースを記述する。
指示的な表現にならないように注意。（「〜であること」のように）
ユーザとシステムの「対話」で構成する。（「ユーザが〜する。システムは〜する。」のように）
この段階で新たにドメインオブジェクトが見つかった場合は、ドメインモデル図を更新する。
文章だが、あとでロバストネス図やシーケンス図などを描く際に簡単に参照できるように、UMLのノート形式で描いておく。
それぞれのユースケースについて、基本コース（正常系）だけでなく代替コース（異常系）も記載する。
ロバストネス図作成
ユースケース記述から、ロバストネス図を描き起こす。
バウンダリオブジェクト・コントローラ（MVCのコントローラーとは違うので注意）・エンティティと外部のアクターで構成する。
WEBアプリならバウンダリオブジェクトはビューやコントローラ、コントローラはインターフェースメソッド、エンティティはモデルに相当する。
したがってバウンダリオブジェクトやエンティティは直接それらと繋がってはならず、
必ずコントローラを介して繋げるというルールになっている。
基本コースと代替コースのどちらについても描画する。
（代替コースは色分けすると見やすくなる。）
作成の過程で新たにエンティティオブジェクトが見つかった場合はドメインモデル図に追加する。
またユースケース記述に曖昧な箇所があった場合は更新する。
またこのタイミングでできる限りドメインに属性を割り当て、ドメインモデル図からクラス図へ昇格させる。
アーキテクチャ設計
シーケンス図を描くにあたって、先にアーキテクチャを決定する必要がある。
クラス図・シーケンス図作成
この段階ではシーケンス図を作成するのがメインの作業になる。
それは、クラスに振る舞いを割り当てる作業になり、クラス図におけるメソッドの割当も同時に行われる。
属性があるところに振る舞いを割り当てるように心がける。
可能な限り「プレファクタリング」し、実装時に「リファクタリング」をしなくても済むようにする。
具体的には、ロバストネス図からアクター・バウンダリオブジェクト・エンティティを抜き出し、まず空白のページに貼り付ける。
次にコントローラをバウンダリオブジェクトやエンティティを繋ぐメッセージとして配置する。
テストコード作成
コントローラ単位で作成する。
（ICONIXでは1コントローラごとに1クラスを推奨している）
モックを使いすぎないように注意する。
個人的に思ったこととしては、repositoryなど依存関係を逆転する必要があるようなクラスだけモックを使う方針に
すればいいんじゃないかと思った（ていうかじゃないと静的型付けの場合はそもそもモックを使えないような）
実装
上記のプロセスでじっくりと設計を行えば、実装はそれをコードで表現するだけの単純作業になる。
ある意味で実装は一種の設計レビューとも言える。
参考文献