アーキテクチャと技術を連続して変えながらアプリケーションを走らせると、脆弱で断片的なコードベースが生まれ、理解やメンテナンスが難しくなる。Mike Hadlow氏は溶岩流または溶岩層とこのアンチパターンを命名し、このアンチパターンが時折表れる理由について自身の経験を書いている。
氏はフリーランスのソフトウエアエンジニアであり、企業向けソフトウエアの世界でこのアンチパターンをよく経験している。特に、大規模でミッションクリティカルで長い間動いているソフトウエアで、社員の配置換えが頻繁な企業で起こりがちだ。また、このアンチパターンはソフトウエアを改善したいと思うときに姿を現す。氏はこのアンチパターンの出現を説明するために、あるアプリケーションについてのフィクションを書いている。これは、氏のたくさんのプロジェクトの経験から生まれたものだ。
新しいアプリケーションの開発は.NETが比較的若いときに始まり、ウェブアプリケーションをASP.NETで作ることになった。設計もMicrosoftの設計ガイドラインに従い、ADO.NET RecordSetを使ってデータアクセス層を作り、Datasetsで直接UI層に公開していた。
アプリケーションはリリースされ、少したったあとに、新しい要件が生まれ、新しいバージョンのための予算が付く。新しいリード開発者は、DALの実装とDatasetsの使い方が気に入らない。そこで、新しい設計を採用する。システムの新しい部分にはオブジェクト指向のアプローチが採用され、テーブルを表現するクラスとコードが関係スキーマから生成される。
さらに数年経って、システムを開発している新しい開発者はふたつの異なるモデルが理解できない。DatasetsもActive Recordも解らないので、3番目のバージョンには新しい設計が採用される。ドメインモデルとObject-Relational Mapper, ORMを使ったアプローチだ。完全な書き直しはできないので、最終的には3つのデータアクセスソリューションと同じ種類の関数の違う実装が生まれる。
これは、フィクションだが、氏は実際にこのようなプロジェクトをよく見ている。一貫した設計戦略や設計哲学がないプロジェクトでは、新しい設計や実装を導入できるが、それが、古いものを完全に置き換えることはほぼあり得ない。その結果、アプリケーションの歴史を示す古層が生まれ、異なる技術的流行が使われる。氏は開発者のシステムをより良くしたいという動きは認めるものの、必要なリソースがなく、結果、氏が名付けた溶岩流というアンチパターンが生まれる。
氏は既存アプリケーションの設計上の変更や技術上の変更は注意深く評価することを推奨している。場合によっては、古いと思われる方式でも、技術的に一貫しているほうがいいかもしれないのだ。