在用戶代碼裏面很少需要使用到這種模式。它主要是爲了支持hivemind module自身的服務存在的（單例模式服務就是建立在幾個由簡單模式創建的服務基礎上的）。
簡單模式的服務創建很簡單，只包括創建核心服務和在必要時生成攔截器。核心服務的生成由指定的生成器完成，攔截器由指定的攔截器工廠生成。
攔截器（Interceptor）簡單點說就是把實際調用的對象包裝起來，並且可以在調用被包裝類的方法之前或之後做一些特定的處理。作爲一個攔截器最大的特點是它必須和被包裝的對象有相同的接口簽名，用戶程序不必關心調用的是攔截器還是實際對象。
攔截器的生成一般有兩種方法。一種是通過動態代碼生成，這種方法的優點是調用開銷小，只需要在生成時需要多一些的系統開銷，缺點是代碼編寫難度大，調試複雜。另一種是通過java.lang.reflect.Proxy類或其它類似於它的技術，通過動態方法調用完成代理的生成，這種方法的優點是易於編寫，但是需要大量的放射調用，增加了調用的系統開銷。具體使用哪種方法生成攔截器HiveMind沒有強制限定，用戶可以在攔截器工廠裏面指定。
HiveMind在解析完模塊描述符（XML配置文件）後，會爲每一個服務擴展點(service-point)生成一個ServicePoint的對象用於管理和生成實際的核心服務。下圖展示了整個類的結構。
一個服務擴展點主要就由上圖確定的結構構成。Schema是用於定義參數格式的，Module是包含個擴展點的模塊。ServiceImplementationConstructor負責生成核心服務，目前HiveMind支持兩種生成方式，一種是直接從指定類生成，一種是由別的服務生成。HiveMind的基本構造工廠BuilderFactory就是由第一種構造方式直接從類生成，這種方式的好處是不需要Schema，不需要其它工廠支持，適合用於作爲最地層的支持服務。ServiceModel是用於管理服務生成規則和生命週期的，目前HiveMind提供了簡單模式，單例模式，與線程綁定模式和基於池模式四種。用戶也可以根據自己的需要可以很方便的對它進行擴展。ServiceInterceptorContribution是用於保存攔截器信息的，它會根據指定的攔截器工廠服務和指定的攔截器生成順序爲核心服務生成攔截器。
現在再回討論簡單模式，當指定服務第一次被引用的時候，PrimitiveServiceModel會直接調用ServiceImplementationConstructor方法生成核心服務。如果有攔截器再調用ServiceInterceptorContribution的集合，依次對核心服務生成攔截器。