Feature聚焦型代码组织下跨功能调用与代码复用解决方案咨询

你提到的问题并不是Feature组织模式的劣势，而是对模式落地细节的误解。以下是针对这类问题的具体解决方案：

1. 拆分「核心基础设施」与「业务Feature」 #

Authentication、Authorization这类全应用通用的基础能力，根本不属于某个业务Feature，应该抽离到独立的核心模块（比如Core/Auth）。各个业务Feature（GetArticle、UpdateArticle等）直接依赖这个核心模块提供的服务，比如调用CheckUserRole()、ValidateToken()方法做权限校验，完全不需要重复编码。

2. Feature间调用：基于接口而非硬依赖 #

像CreateOrder需要调用CheckProductAvailability这类业务Feature间的交互，不能直接引用对方的内部代码，要通过公共接口解耦：

• 在CheckProductAvailability Feature中定义IProductAvailabilityChecker接口，暴露核心能力（比如IsProductAvailable(string productId, int quantity)）
• CreateOrder Feature只依赖这个接口，通过依赖注入获取实现
• 这样既保证了每个Feature的独立性，又避免了重复写库存校验逻辑，后续还能轻松替换校验规则

3. 业务逻辑复用：抽离「业务组件」而非通用工具 #

如果多个Feature需要用到同一段业务逻辑（比如SendOrderEmail），不要复制代码，而是把它包装成业务聚焦的独立组件。比如专门做订单邮件的OrderEmailSender，而不是一个能发所有邮件的通用邮件服务——这样既保证了复用，又不会因为过度通用导致后续维护混乱。

4. 调整Feature粒度：避免过度拆分 #

GetArticle、UpdateArticle、CreateArticle本质上属于「文章管理」同一个业务域，没必要拆成三个独立Feature。可以把它们放在ArticlesFeature下，内部再分Commands（Create/Update）和Queries（Get），权限校验这类公共逻辑可以在Feature内部的基类或者拦截器里统一处理，不用每个子功能重复写。

总结 #

Feature组织模式的核心是清晰划分业务边界，不是禁止代码复用。所谓的“重复编码”问题，大多是因为把基础服务和业务Feature混为一谈、拆分粒度不合理，或者用了错误的依赖方式。只要把握好以上几个原则，就能在保持业务清晰的同时，充分享受代码复用带来的效率提升。

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