http://wiki.c2.com/?ArchitectureByImplication
日本語のタイトルからその意味をもっとも誤解されやすいのがこの文書化軽視パターンです。このアンチパターンが語っているのは、成果物としてのドキュメントではなく、実装前のアイデア整理のためのドキュメントです。ポイントは文書を残すことではなく、「プログラミングの前に、まず母国語で考えろ」ということです。
英語では Architecture By Implication と名付けられていますが、こちらの方がそのゴールをうまく物語っています。Implication (含意) の逆は Explication (説明) です。言語化されたアイデア分析のプロセスといったニュアンスを持つ言葉です。
書籍の中で日本語タイトルや本文内容が文書化を強く主張しているのは、おそらく、アンチパターン本が書かれた時点では、まだそのためのツールがドキュメントしかなかったからだと思われます。つまり、当時まだこの世にテスト駆動開発が存在しなかったということです。
設計手法としての TDD は、先にアイデアに名前を付けさせ、その仕様をテストケースで表現するという点で、当時ドキュメントしかなかったのに代わって、画期的な仕様説明手法となりました。実践的モデラーによるドメインモデルのプロトタイピングにおいては、文書より優れているかもしれません。
手法は何であれ、このアンチパターンが主張したいのは、要求に応じた動きをいきなり実装した結果は、アーキテクチャではないということです。そこには、アイデア整理から生まれた語彙 (DDD でいうユビキタス言語) の代わりに、実際に動かして試さなければわからない「仕様(笑)」があります。
解決のための手続きしか書かれていないと、コードは非常に脆くなります。なぜなら、その部分に「何であるか」を指す名前が付いていないからです。各自が詳細手続きの意味をそれぞれの視点で解釈すると、誰も読めない スパゲティコード 化がどんどん悪化していきます。
実際の動きはモックオブジェクトで代替してもよいので、まずコードを読んだときそれが何であるかを正しく理解できるように記述することが大事です。アーキテクチャをアーキテクチャたらしめるのに最も重要なのは、現象の結果ではなく、概念の説明です。実行時のコンピューターにとって何の意味もないそれは、ソースコードにとっては自身の強度を保つための、大事な形状構造=アーキテクチャです。
あ、でもいくらゴールがアーキテクチャだからって、それだけじゃメンバーがしんどいですよね。適度な自然言語はチーム開発にすごく有用なので、そっちもちゃんと活用しましょうね。