昨天的設計總監把 Grimo 的視覺語言搞定了。

今天，我要扮演架構師。

在一人公司裡，技術選型沒有漫長的會議和討論，只有我一個人的主觀判斷和滿滿的自信。

架構師的主觀偏見

說實話，我在開始調研之前就已經有了強烈的技術偏好。

我想要用 Spring Boot + Spring AI 做後端。為什麼？因為這是我最熟悉的 Java 生態，閉著眼睛都能寫。前端想試試 Compose Multiplatform，聽起來很現代化，是 JetBrains 的新寵。部署要做成單一 macOS 應用程式，支援 .dmg 拖拉安裝。

為什麼這樣選？

舒適圈理論。Spring Boot 是我的主戰場。追新心態，Compose Multiplatform 看起來很酷。還有完美主義作祟，既然要做桌面應用，當然要做成「一個檔案解決所有問題」。

委託 Gemini 做技術研究

帶著這些預設立場，我開始了技術研究。作為一人公司的架構師，我善用 AI 助手來加速研究過程。

第一個問題丟給 Gemini：「我要用 Java 開發 MAC 應用有什麼選擇？」

Gemini 詳細列出了各種選項。JavaFX、Swing、SWT，還有 Compose Multiplatform。我大致看過幾個方案的內容後，接著問第二個問題：「教我用 Compose Multiplatform 跟 Java 21 Spring Boot + Spring AI 來開發 mac 應用程式，並可以使用拖拉式安裝」。

注意。

我並沒有問「應該用什麼技術」，而是直接問「怎麼用我想要的技術」。這就是架構師的自信（或固執）。

Gemini 的詳盡研究報告

Gemini 很專業地提供了一份完整的技術分析，包含了一個重要的架構建議。

它推薦分離進程架構。Compose Desktop 作為主進程負責 UI 渲染和進程管理，Spring Boot 作為子進程負責 AI 邏輯和 REST API，兩者透過 HTTP/REST 通訊。

┌─────────────────────┐    HTTP/REST    ┌──────────────────────┐
│  Compose Desktop    │ ─────────────→  │   Spring Boot        │
│  (主機進程)          │                 │   (子進程)            │
│  - UI 渲染          │                 │   - AI 邏輯           │
│  - 進程管理         │                 │   - REST API         │
└─────────────────────┘                 └──────────────────────┘

Gemini 詳細解釋了這種架構的優點。關注點分離清晰、技術棧獨立不會相互干擾、易於測試和維護、符合業界最佳實踐。

聽起來很合理。

但我憑野性的直覺提出需求

看完 Gemini 的分析後，我提出了一個關鍵問題：「或是可以在同一個 JVM 運行嗎？」

這個問題背後的思考很簡單。

簡化部署，單一執行檔更容易分發。資源效率，避免進程間通訊開銷。開發便利，直接方法調用比 HTTP 簡單。用戶體驗，一個 .app 檔案，拖進去就能用。

Gemini 的深入分析

面對我的追問，Gemini 提供了更深入的技術分析。

理論上可以在同一個 JVM 運行，但需要注意幾個關鍵點。它給出了實作建議：

object SpringManager {
    private var context: ConfigurableApplicationContext? = null

    fun start() {
        Thread {
            context = SpringApplicationBuilder(BackendApplication::class.java)
                .web(WebApplicationType.NONE)  // 非 Web 模式
                .headless(false)               // 支援 UI
                .run()
        }.start()
    }
}

Gemini 也提出了這種架構的複雜性考慮。生命週期管理需要協調、依賴版本可能衝突、線程模型需要隔離、ClassLoader 管理要小心。

架構師的最終決策

但我基本上沒有管什麼複雜性。

我做出了架構決策：採用單一 JVM 架構。

決策理由很直接。用戶體驗優先，單一 .app 檔案拖拉安裝最簡單。資源效率，避免額外的進程和端口佔用。開發效率，直接調用比 HTTP 請求簡單。還有一個私心，這是一個有趣的技術挑戰。

技術棧確認下來了。UI 框架用 Compose Multiplatform，現代化、宣告式 UI。後端框架用 Spring Boot 3，成熟、完整的生態系統。AI 整合用 Spring AI，統一的 AI 模型抽象。程式語言用 Kotlin + Java 21，互操作性佳。架構模式就是單一 JVM，簡化部署和用戶體驗。

實作規劃

專案結構很清晰：

grimo/
├── backend/         # Spring Boot 模組（非 Web 模式）
├── desktop/         # Compose Desktop 模組
└── shared/          # 共享的領域模型

核心整合邏輯也不複雜。先啟動 Spring Context，再啟動 Compose UI。兩個框架在同一個 JVM 裡和諧共處。

Gemini 提供的實作細節

Gemini 不但提供了架構建議，也給出了詳細的實作指南。

依賴注入整合可以透過橋接 Spring 和 Compose 來實現。生命週期管理需要協調兩個框架的啟動順序和優雅關閉。這些細節都有對應的程式碼範例。

信心滿滿的期待

完成技術選型後，我對這個架構充滿信心。

Spring Boot 和 Compose 都是成熟框架，整合應該順利。單一 JVM 部署會帶來極佳的用戶體驗。Kotlin 和 Java 的互操作性經過多年驗證，應該沒問題。

一人公司架構師的優勢

這次技術選型展現了一人公司的特色。

決策效率極高。沒有冗長的技術委員會討論，可以快速做出大膽的技術決定，完全按照產品願景選擇技術。

AI 協作模式也很有效。我負責戰略方向和最終決策，Gemini 負責技術調研和風險分析。結合人類直覺與 AI 的資訊處理能力，這是一人公司的超能力。

即將開始的技術冒險

明天就要開始實作這個「創新」的單一 JVM 架構了。

我相信憑藉我的 Spring 經驗和 Gemini 的詳細指導，這個技術組合會工作得很好。

不過，理論和實作之間，有時候隔著一座意想不到的高山。

明天就會知道，這座山有多高了。

今日金句

「在一人公司裡，技術選型的會議很短——因為只有你自己，而且你早就決定好了。」

關於作者：Sam，一人公司創辦人。正在打造 Grimo，一個智能任務管理和分配平台。

專案連結：GitHub - grimostudio