rust的main.rs和lib.rs该怎么写

🧠 一句话理解：

• main.rs 是程序的“入口” —— 负责“接线”，不写业务逻辑；
• lib.rs 是程序的“内核” —— 组织你的领域层、应用层等逻辑模块，供 main.rs（或测试）调用。

🗂️ 文件职责对比表

✅ main.rs 应该写什么？

在 src/main.rs 中，建议这样写（适合 CLI 工具）：

fn main() {
    // 初始化日志、解析 CLI 参数
    let args = xshell::presentation::cli::parse_args();

    // 加载配置（来自配置文件、env）
    let config = xshell::infrastructure::config::load_config();

    // 执行业务逻辑（调用 orchestrator）
    if let Err(e) = xshell::application::orchestrator::run(args, config) {
        eprintln!("Error: {:?}", e);
        std::process::exit(1);
    }
}

👆 main.rs 的职责是组织调度，调用 lib.rs 中暴露的能力，不要包含任何业务逻辑。

✅ lib.rs 应该写什么？

在 src/lib.rs 中：

pub mod presentation;
pub mod application;
pub mod domain;
pub mod infrastructure;

如果你想为测试暴露一套 API，可以这样写：

pub use application::orchestrator::run;

甚至可以在这里做一层封装暴露简化 API：

pub fn execute(args: Args) -> Result<()> {
    let config = infrastructure::config::load_config();
    application::orchestrator::run(args, config)
}

📦 如果是用于测试的结构（TDD驱动）

你可以直接在 lib.rs 中写：

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_runs_successfully() {
        let args = /* mock args */;
        let config = /* mock config */;
        assert!(application::orchestrator::run(args, config).is_ok());
    }
}

这样你的业务核心逻辑就完全与 CLI、主函数解耦了。

🧱 推荐的执行流结构（DDD+CLI）

main.rs ─→ cli.rs
           │
           ↓
      orchestrator.rs
           │
           ↓
      domain/* + infrastructure/*

✅ 总结一句话：

• main.rs：只管组织程序流程、入口、参数解析，不做“事”。
• lib.rs：暴露架构核心模块，便于测试和复用，是你“可被调用”的 DDD 内核。