rust的main.rs和lib.rs该怎么写
🧠 一句话理解:
main.rs
是程序的“入口” —— 负责“接线”,不写业务逻辑;lib.rs
是程序的“内核” —— 组织你的领域层、应用层等逻辑模块,供main.rs
(或测试)调用。
🗂️ 文件职责对比表
文件 | 作用 | 内容建议 | 是否包含逻辑 |
---|---|---|---|
main.rs | 应用程序入口(Presentation) | 解析命令行、调用 lib 中逻辑 | ❌不包含业务逻辑 |
lib.rs | 统一导出模块,组织架构 | pub mod xxx; ,DDD层统一暴露接口 | ✅组织逻辑模块 |
✅ 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 内核。