當我們在軟件設計中想應用設計模式時，往往是憑藉設計模式的名字和需求有點類似，之後就嘗試着將模式生搬硬套到其中。而真正去理解設計模式往往變得比較困難，很多書籍也僅僅是用不同方法來降低模式記憶的強度。難道設計模式不能從更加細微的層面去理解嗎？當然可以，設計模式就像可以再分解的化合物一般是可在分解，這種再分解後的模式叫做元素模式（elemental design patterns , EDP）。
元素模式重申了一個非常重要的思想：模式是概念，而不是結構。GoF也這樣認爲：“假設某語言是面向過程的語言，那麼它可能就會擁有一批被我們稱爲‘集成’、‘封裝’和‘多態’的設計模式。”，顯然GoF認爲模式是語言無關的概念。在面嚮對象語言中可能已經有了“封裝、集成和多態”的概念，但在面向過程的語言中同樣可以通過設計模式達到這些概念的效果。兩者不同的是，或者不同語言間不同的是，在一種語言中一些概念已經根深蒂固的被深入的理解，甚至是內嵌到了語言特性中，在另一種語言中他們卻尚未被充分理解，但可以用模式的結構協助我們理解。
那麼元素模式是通過什麼方式分解出來的呢？我們閱讀設計模式相關文獻可以瞭解到設計模式涉及11個方面：意圖（intent）、動機（Motivation）、適用性（applicability）、結構（structure）、參與者（participants）、合作（collaborations）、結果（consequences）、實現（implementation）、示例代碼（samples code）、已知應用（known uses）、相關模式（Related patterns）。設計模式是特定語境下的常見問題的常用解決方案,權威形式的設計模式,它的大部分片段都可以很容易的歸爲三類:解決方案、問題以及語境。我們可以將上文提到的模式的組成片段整理到模式定義的這三個類別中去，如下表所示。
|
解決方案 |
結構 實現 示例代碼 |
|
問題 |
意圖 動機 已知應用 |
|
語境 |
應用範圍（適用性） 結果 相關模式 |
上表的三個分爲並沒有將設計模式涉及的角參與者（participants）和協作活動（collaborations）包含在內。而由於這兩者存在的環境（語境）中常常存在問題，而他們有反映着問題的現象，同時它們還構成了問題解決方案的一大部分，所以這兩者貫穿於上表的三種類別。總之參與者和協作活動在上表描述的設計模式的三個分支的交叉點上描述着設計模式的組成部分，以及這些部分的關係。由此可見關係構成了設計的核心。
參與者和協作活動所表述的關係會有很多種，從簡單到複雜，那麼什麼樣的關係纔是元素模式所真正關心的呢？既然設計模式可以進一步分解，就應該將其分解到最小單元，而兩個事物間最簡單的關係則是單一關係。從而得知我們可以將設計模式中的複製的關係網分解爲這種單一關係，而這種關係往往是方法對另一個方法的調用依賴關係，我們稱之爲關鍵關係。元素模式就是由此而逐漸演化推導而來的，也是後續深入理解設計模式的基礎。