任你选择
课程对象
有一定 C#/.NET 开发经验，希望提升代码质量与业务建模能力的开发人员 / 技术负责人
课程大纲
第一天：依赖注入、MVVM 与整洁代码基础上午（3h）
模块 1：依赖注入（Dependency Injection）原理与实战
目标：理解为什么要用DI、DI 和 DIP 的关系，并能在 .NET 中熟练使用DI 容器。
1、问题背景与设计动机
l “到处 new ” 带来的问题：难以测试、难以替换实现、难以扩展
l 高内聚、低耦合、解耦对象创建与使用
2、依赖倒置原则（DIP）与接口驱动设计
l 高层模块不应该依赖低层模块，而应共同依赖抽象
l 面向接口编程 vs 面向实现编程
l 用简单 C# 例子说明：从 new SqlOrderRepository() 到依赖 IOrderRepository
3、DI 的三种常见方式
l 构造函数注入（推荐）
l 属性注入/ 方法注入的适用场景与缺点
l 如何选择注入方式
4、NET 中的 DI 容器使用
l IServiceCollection / IServiceProvider 基本机制
l 生命周期： Transient / Scoped / Singleton
l 在 ASP.NET Core / 控制台应用中注册与解析依赖示例
5、动手练习
l 将一份“硬编码 new 依赖”的示例服务，重构为
：定义接口
使用DI 容器进行注册和注入
l 分析重构前后的可测试性、可扩展性变化
下午（3h）模块 3：整洁代码与重构入门
目标：建立代码质量意识，学会识别坏味道并掌握基础重构技法。
1、什么是“整洁的代码”
l 可读性、可维护性、可扩展性
l 代码与架构的关系：先有好代码，才能有稳固架构
2、典型坏味道（Code Smell）识别
l 过长方法、过长类、神对象
l 命名混乱、重复代码、过深嵌套
l 业务逻辑和基础设施代码混在一起
3、命名与表达力
l 类 / 方法 / 变量命名原则
l 如何通过命名使代码更接近业务语言
l “见名知意”与“上下文自解释”
4、常用重构技法（C# 版本）
l 提取方法 / 内联方法
l 提取类 / 内联类
l 引入参数对象
l 卫语句、拆分复杂条件、消除嵌套
5、实战：整理一段“烂代码”
l 提供一段真实感较强的 C# 业务代码
l 引导学员：
标注坏味道
讨论可能的重构方案
分步进行重构并对比前后差异
第二天：设计模式实践与领域驱动设计（DDD）
上午（3h）模块 4：设计模式与重构实践
目标：通过重构引入设计模式，提升复杂逻辑的可维护性，不做“为模式而模式”。
1、SOLID 原则快速回顾
l SRP / OCP / LSP / ISP / DIP 简要解释
l 示例：订单处理 / 支付流程中的 SRP 和 OCP
2、从坏味道到模式：以策略模式为例
l 大量 if-else / switch 集中在一个方法里的问题
l 使用策略模式替代复杂条件逻辑的典型场景
l C# 实现策略模式：
定义策略接口
多个具体策略类
上下文类如何通过 DI 注入策略
3、几个常用设计模式在业务代码中的落地
l Strategy：定价策略、折扣策略、路由策略等
l Factory / Abstract Factory：隐藏对象创建细节
l Adapter：对接第三方服务或旧系统时的适配
l Template Method：统一处理流程，开放差异点
4、测试与模式
l 设计模式如何帮助更易于单元测试
l 使用接口和依赖注入，让测试替换实现变得简单
5、实战：由需求出发设计模式
l 给出一个业务需求（例如：多种运费计算方式 / 多渠道支付）
l 学员分组讨论：
用简单方式实现会遇到什么问题？
如何用策略模式 + DI 组合进行重构？
l 各组展示方案与代码片段
下午（3h）模块 5：领域驱动设计（DDD）原理与实践
目标：理解 DDD 的核心概念，能在中等规模的业务中尝试用DDD 思想进行建模。
1、为什么需要 DDD
l 系统变复杂时，单纯“加类、加 Service”为什么不再有效
l DDD 关注点：用领域模型对齐业务与代码
2、领域 / 子域 / 限界上下文
l 业务领域与子域拆分：核心域、通用域、支撑域
l 限界上下文（Bounded Context）：为什么不能全系统共用一个模型
l 示例：
电商：下单、库存、支付、结算
或 项目管理：任务、资源、排期、结算
3、通用语言（Ubiquitous Language）与代码
l 与领域专家一起定义术语
l 将通用语言映射为 C# 类名、方法名、模块名
l 避免“技术名词”淹没业务意图
4、战术建模：实体 / 值对象 / 聚合
l 实体与值对象的区别与设计方式
l 聚合与聚合根：一致性边界
l 示例：订单聚合、客户聚合等建模练习
5、分层架构与 .NET 项目结构
l 应用层 / 领域层 / 基础设施层的职责
l 在解决方案结构中的典型拆分方式：
MyApp.Domain
MyApp.Application
MyApp.Infrastructure
MyApp.Api （或 UI 层）
6、应用服务 / 领域服务 / 仓储（Repository）
l 各自的职责与边界
l 示例：
订单应用服务：协调用例流程
订单聚合内部业务逻辑：保持领域规则
仓储接口+ 基于 EF Core 的实现思路
7、总结与实践建议
l 如何从现有系统逐步演进到更“DDD 化”的结构
l 推荐的下一步实践：
选一个中等复杂度业务场景做 DDD 试点
建立团队的通用语言
逐步重构而非推倒重来
C#编程进
