為什麼要提 KMM 呢？ 因為我會寫

因為 KMM 的架構其實在某種程度上讓我們必須為其做分層，倒不如說層級不分，就不能寫ＸＤ

這篇主要就 KMM 的專案架構和昨天的整潔架構做討論，要是真想學，請轉我大哥俊廷的(裝熟呀) Kotlin 全面啟動

然後懶人如我，秉持著不要重造輪子的原則，今天的圖都是借來的ＸＤ，是全面啟動的第七篇，來源也放在下面了

project structure

回到正題，今天就一個重點，架構！！

而 KMM 的專案架構，最最最基本的就長這樣

還有陰影效果耶太用心了吧

基本上你要有點模組化的基本知識，很簡單的，白話講就是把功能拆出去再引用回來，難就難在怎麼拆才好，版本相容等等，稍微複雜一點的模組化架構會長這樣

沒關係，今天主題不是模組化，要講的是 KMM 專案結構

在多平台這裡，我們會有安卓模組，蘋果模組，以及共用模組，如果要將其對應到整潔架構的話，根目錄的安卓以及蘋果模組，基本上就對應到同心圓的最外兩層了，原因很簡單，在這不同的兩個平台，安卓會用 Kotlin 實現，而蘋果則是用 Swift，而專案內部的架構和接口，不論是用 MVVM, redux 都已經是獨立的實現了

那在整潔架構中，朝著中心去看，內圈兩層會在哪裡呢？
答案是 Shared 模組裡面，在 Shared 模組，裡面又分為了

commonMain, androidMain, iosMain 三個子模組，莫急莫慌莫害怕，這也很簡單

• commonMain
  • 主要編寫能完成支持 KMM 方法
    • 輸入、輸出純 Kotlin 的資料 ex. String
    • java.io.File 不行
  • 使用以支持 KMM 的套件，例如 kotlinx.datetime
  • 編寫跨平台的抽象介面
• androidMain, iosMain
  • 以各平台方式實現抽象介面

就是這麼簡單又樸實無華，那這就一定對到了內圈兩層嗎？
誒，不完全是，我們可能會將共用的資料類別寫在 commomMain 裡面，也可能對不同平台有不同資料類別，所以寫在 androidMain, iosMain 之中，但可以肯定的是，androidMain, iosMain 主要負責了架構的第二層，而 commonMain 主要負責的是最內層

但是！！！就像我一直說的，不要被層級迷惑了，不是每個模組只會有一種層級，只要你有好理由，就為其做出最適合的設計，整個整潔架構不是死板的法律，更像是一種模式，如果只會死板的硬套模式到專案裡面，最後的成品終究只是糙 code

那現在我們再由內而外複習一遍，KMM 和 clean architecture 到底有什麼關係

1. shared/commonMain 負責核心業務邏輯，在兩個平台都會用到，且規則一樣，在這邊的可能有實作可能只有抽象
2. shared/androidMain, iosMain 負責應用程式特定規則，用各自平台的語法、套件完全抽象業務邏輯的實作
3. 介面轉接層, 可能是 repository, viewModel 等等，或是 data mapper ，可能會在 shared/androidMaim ,iosMain 也可能在 androidApp 或是 iosApp
4. androidApp, iosApp 框架和驅動層，使用各平台的套件完成整個功能

resource

圖片資源 [Kotlin 全面啟動] 專案結構

English

Why should we know about Kotlin multiple platforms from mobile? because I know how to write it

Because the architecture of KMM, actually make us have to follow clean architecture in some point, well, on the other hands, we can't write kmm project without separate the layer

This article focus on KMM project structure with clean architecure yesterday, for more information about KMM, check this articleKotlin 全面啟動

And base on the principle of do rebuild the wheels, I borrow some image from that article as well

project structure

Well, back to the point, architecture

The basic project structure of kmm, look like this

This require basic knowledge of modularization, but we can understand in a simple sentence, separate function and use it when you need it, the difficult part is spec to separate, dependency version ...etc, the normal modularization look like this

But modularization is not topic today, I might talk about that at future

In the KMM, we have androidApp module iosApp module, and shared module, to fit it into clean architecture, the androidApp and iosApp under root directory correspond to interface Adapter and Framework and Driver layer, the reason is in different platform, android will use Kotlin, while ios use swift, and application structure using MVVM or redux and others, is their own business

And where are Application business layer and Enterprise business rule?
Those are belong to Shared module, inside shared module, we have comminMain, androidMain and iosMain

• commonMain
  • include function which support KMM
    • input, output in pure Kotlin data format, ex String
    • Not something like java.io.File
  • using library support KMM, ex. kotlinx.datetime
  • abstract interface for each platform, expect class
• androidMain, iosMain
  • implement abstract interface on each platform, actual class

That is so easy, but do those perfectly fit Application business layer and Enterprise business rule?
Not exactly, We might have reuse data class inside commonMain, or different data class in androidMain, iosMain, but one thing for sure, androidMain, iosMain basically incharge of Application business layer, and commonMain incharge of Enterprise business layer

BUT!!! As I mentioned before, do not confused by layer, each module might have one or multiple layer, as long as you have good reason, you should make a design suit your project, clean architecture is not law, it is more like a pattern, if you force to pattern into your project, it most likely will become a bunch of shit

Well, now let's review relationship between KMM and clean architecture from inner to outer

1. shared/commonMain, in charge of enterprise business logic, have same logic and will be used in each platform, it might be real logic or abstract
2. shared/androidMain, iosMain, in charge of application business logic, using platform syntax, library to implement abstract business logic
3. Interface adapter, could be repository, viewModel ...etc, or data mapper, could exists in shared/androidMaim ,iosMain or androidApp/ iosApp
4. androidApp, iosApp framework and driver using library to finish whole function

resource

圖片資源 [Kotlin 全面啟動] 專案結構