为什么需要引入子模块？
随着代码量的增加，相关逻辑日渐复杂，需要维护的状态和传递的消息也迅速的增加起来。
Elm 的架构文档中并没有详细说明如何组织比较复杂的项目，我调查中看到的文章中的方案也大多仍然需要模块间的耦合，实际使用中并不能得到满意的效果。
期望达到的效果
首先需要做到的是代码层面的分离，模块内部实现细节的修改对外部来说尽量不可见，减少代码的耦合程度，便于开发。
下一个阶段的目标是模块的可重用性，除了简单的函数层面的重用，在更高层次上也有很多相似性，例如如果由于应用场景的考虑，需要发布多个微信小程序的话，其中有不少逻辑是可以共用的，例如微信端用户登录、信息获取，服务后台的 Session 管理，等等。
模块之间的交互应尽量简单，可以用可维护的方式进行组织。
如何拆分子模块
个人的习惯是先从数据开始设计，在 Model 的部分先做分割，之后进行 Msg 的设计，宗旨是把聚合度高的部分放在一起，封装成独立的模块。
子模块间如何交互
多个模块需要彼此协调才能完成完整的应用逻辑，根据具体情况有以下的情境
数据依赖
某个模块需要外部提供所需的数据，有几种处理的方法，可以根据具体需要进行选择
- 作为输入事件的参数传递进来，只在相关事件的处理中使用
- 封装成内部的数据，加入 Model，在需要时访问
- 作为 update 方法的参数，每次更新时都可以访问到
事件触发
对于子模块来说，其实不用了解事件的具体来源，可以是模块自身，可以是其它模块，或是应用层面的用户输入。只要把自身的生命周期管理好即可，由于 Elm 架构的函数式和不可变特性，一般来说调试也很方便，只要观察 Msg 的序列以及相应的 Model 的变化往往就能找到问题所在。
WxApp 子模块
由于所有的微信小程序都需要进行用户身份的管理，在 elm-wx-app 中提供了一个基本的身份认证子模块，在 API 调用之上提供了更高一层的接口。
下面列出了部分的代码，结构相对比较简单，感兴趣的话可以 Clone 完整的版本。
（目前的版本还比较简单，接口也没有完全固定下来）
Model
type alias Type =
{ systemInfo : SystemInfo.Type
, userCode : String
, userInfo : UserInfo.Type
, userSecret : UserSecret.Type
, tabs : List UiTab.Type
, currentTabKey : UiTab.Key
, pages : List UiPage.Type
}
Msg
type Msg
= DoInit
| DoGetSystemInfo
| DoCheckSession
| DoLogin
| DoLoadWxModel
| DoGetUserInfo
| GetSystemInfoMsg (Result Error GetSystemInfo.Msg)
| CheckSessionMsg (Result Error CheckSession.Msg)
| LoginMsg (Result Error Login.Msg)
| LoadWxModelMsg (Result Error WxModel.Type)
...
update
update : Msg -> Model -> (Model, Cmd Msg)
update msg model =
case msg of
DoInit ->
( model
, cmd DoGetSystemInfo
)
DoGetSystemInfo ->
( model
, GetSystemInfo.cmd GetSystemInfoMsg
)
DoCheckSession ->
( model
, CheckSession.cmd CheckSessionMsg
)
DoLogin ->
( model
, Login.cmd LoginMsg
)
...
WxApp Wrapper 实例分析
wrapper
wrapper 的细节请看 elm-component-updater 的实现代码，基本上是从主模型中访问子模型（get），调用子模块的 update，之后再把返回的子模型更新到主模型中（set）
wrapper : Wrapper Msg Wx.Msg
wrapper =
wrap WxMod
{ get = Just << .wx
, set = \modModel model -> { model | wx = modModel }
, update = Wx.update
, react = reaction
}
cmd msg =
toCmd msg
|> Cmd.map wrapper
reaction
reaction 的目的是对于特定的子模块事件产生相应的外部事件，来达到对其他模块的控制。
reaction modMsg modModel model =
model ! []
|> case modMsg of
Wx.PopPageMsg pageKey (Ok _) ->
case List.length modModel.pages of
0 ->
addCmd <| cmd <| Wx.SwitchTab "dialogue"
_ ->
noOperation
_ ->
noOperation
主应用中的相关代码
model
首先是在 Model 中包含子模块的部分
type alias Type =
{ rev : Int
, wx : Wx.Model
...
事件定义
import Updater
import WxApp.Mod as Wx
type alias Delegate = (Updater Model Msg)
type Msg
= WxMod Delegate
| WxMsg Wx.Msg
WxMod 代表由 Wrapper 处理的事件，WxMsg 则是普通事件，需要在 update 中转换为 Wrapper 事件。
这里做区分的原因是在 Elm 中无法循环 import，在被 WxApp Wrapper 引用的代码中如果也需要通知 WxApp 的模块，则只能产生一个 WxMsg 类型的事件。
update
import Wrapper.Wx as Wx
updateMod : Msg -> (Model, Cmd Msg) -> (Model, Cmd Msg)
updateMod msg (model, cmd) =
case msg of
WxMod delegate ->
delegate model
WxMsg msg ->
(model, Wx.cmd msg)
...
可以看到这里对于 WxMsg 类型的事件使用 wrapper 做了一次转换，略显繁琐，不确定是否有更好的方式。
总结
实际开发中应用以上方式写了不少代码，在模块的分隔上感觉还是一种不错的方法。
在需要调整模块结构的情况下，Elm 作为静态类型语言提供了很大的帮助，编译器可以发现不匹配的接口，重构起来有一气呵成的感觉。