函数式编程视角下Clean Architecture分层依赖维护问题咨询

核心结论 #

函数式编程完全可以适配Clean Architecture，且能通过类型约束+依赖参数化替代OOP的接口来维护依赖方向，同时不违背纯函数、不可变等核心原则。

一、用类型替代接口维护依赖方向的实现思路 #

OOP依赖接口抽象实现依赖反转，函数式场景下则通过定义“依赖抽象类型”+ 函数参数注入达成同样效果，核心逻辑是：

• 领域层完全独立，仅包含纯领域类型与纯函数，不依赖任何外层组件。
• 应用层定义用例的输入输出类型、依赖抽象（用函数类型的记录表示），用例函数将依赖作为参数接收，通过管道组合领域函数与依赖调用完成业务流程。
• 基础设施层实现依赖抽象的具体逻辑，启动时将实现注入用例函数。

以下是F#示例代码：

// 领域层（Domain）
type OrderId = OrderId of string
type Order = { Id: OrderId; Status: string }
type DomainError = NotFound | InvalidId

// 纯领域函数：仅操作领域类型，无外部依赖
let validateOrderId (OrderId id) =
    if String.IsNullOrEmpty(id) then Error InvalidId else Ok (OrderId id)

// 应用层（Application）
type GetOrderUseCaseInput = { OrderId: string }
type GetOrderUseCaseOutput = Result<Order, DomainError>

// 依赖抽象类型：定义需要外部提供的能力
type IOrderRepository = {
    GetOrder: OrderId -> Result<Order, DomainError>
}

// 用例函数：依赖作为参数传入，本身是纯函数
let getOrderUseCase (repo: IOrderRepository) (input: GetOrderUseCaseInput) =
    input.OrderId
    |> OrderId
    |> validateOrderId
    |> Result.bind repo.GetOrder

// 基础设施层（Infrastructure）
// 依赖抽象的具体实现：包含数据库访问等副作用逻辑
let sqlOrderRepository = {
    GetOrder = fun (OrderId id) ->
        // 模拟数据库查询逻辑
        if id = "123" then Ok { Id = OrderId "123"; Status = "Shipped" }
        else Error NotFound
}

// 启动时注入依赖，得到可执行的用例
let getOrder = getOrderUseCase sqlOrderRepository
// 调用用例
getOrder { OrderId = "123" } // 返回 Ok { Id = OrderId "123"; Status = "Shipped" }

这种方式下，依赖方向依然是外层（Infrastructure）依赖内层（Application、Domain），完全符合Clean Architecture的规则，同时保持了函数式的可测试性（可传入Mock依赖）与纯函数特性。

二、函数式Clean Architecture的分层组织建议 #

可以严格遵循Clean Architecture的分层逻辑，按职责分离类型与行为：

• 领域层：
  • 值对象、实体、领域错误等核心类型定义
  • 纯领域函数（验证、状态转换、计算逻辑等，无任何外部依赖）
• 应用层：
  • 用例的输入/输出类型
  • 依赖抽象类型（外部服务的能力定义）
  • 用例实现函数（业务流程编排，组合领域函数与依赖调用）
• 基础设施层：
  • 依赖抽象的具体实现（数据库、外部API、消息队列等）
  • DTO与领域类型的转换逻辑
• 接口层：
  • API控制器、CLI、UI等，负责接收外部输入、调用应用用例、返回结果

这种结构下，类型与行为按职责分层存放，而非同一文件夹，完全符合函数式关注点分离的原则。

三、可参考的实践示例 #

你提到的项目已包含函数式Clean Architecture的核心实践：

• 《Domain Modeling Made Functional》示例：其中的工作流（Workflow）就是应用层用例的雏形，依赖通过参数传入，领域层保持纯函数特性。
• Dumia（F#电商示例）：明确划分了Domain、Application、Infrastructure层，Application层定义用例与依赖抽象，Infrastructure层实现外部依赖，完全遵循Clean Architecture的依赖规则。

对比C# OOP示例的分层逻辑，只需将接口替换为函数类型的记录，将类方法替换为接收依赖参数的纯函数，即可映射到函数式实现。

内容的提问来源于stack exchange，提问作者user1790300