第三章：领域工程与产品工程
好，咱们今天聊一个核心话题。很多团队做产品线，做着做着就乱了。为什么？
说白了，就是没搞清楚「领域工程」和「产品工程」到底谁该干什么。我见过不少项目，架构师跑去写具体产品的业务代码，产品经理又跑来定义底层组件。嗯，这肯定要出问题。
3.1 领域工程的角色
领域工程，你可以把它理解成「造轮子的人」。它的目标不是交付一个具体产品，而是交付一套可复用的资产。
我个人习惯把领域工程比作「兵工厂」。兵工厂不直接上战场打仗，但它负责生产枪炮子弹。前线战士（产品工程）拿着这些武器去打赢具体的战役。
领域工程的核心产出：
- 领域模型（Domain Model）
- 可变性模型（Variability Model）
- 核心资产库（Core Asset Base）
- 产品线架构（Product Line Architecture）
我在项目中遇到过一件事。有个团队做电商产品线，领域工程组花了三个月，把订单、支付、库存这些核心模块的通用逻辑全部抽象出来了。结果产品工程组说：「你们做的这些我们用不上，太抽象了。」
为什么会这样？因为领域工程只顾着「造轮子」，没去前线看看战士到底需要什么口径的子弹。这是个教训。
3.2 产品工程的角色
产品工程，就是「上战场的人」。它的目标很明确：在特定时间、特定预算内，交付一个满足客户需求的具体产品。
产品工程不需要关心底层框架怎么搭，也不需要操心通用性。它只需要做一件事：从核心资产库里拿东西，然后快速组装、定制、交付。
产品工程的核心职责：
- 需求分析：搞清楚这个具体产品要什么
- 资产绑定：从领域工程拿来的资产中做选择
- 可变性解析：把「可选」变成「确定」
- 产品构建：快速交付可运行的产品
你想想看，如果产品工程组的人天天去改底层框架，那跟传统开发有什么区别？产品线工程的价值就没了。
3.3 两者如何协同工作
好，重点来了。领域工程和产品工程怎么配合？
我总结了一个简单的原则：领域工程负责「定义可能性」，产品工程负责「实现确定性」。
| 维度 | 领域工程 | 产品工程 |
|---|---|---|
| 关注点 | 共性 + 可变性 | 具体需求 |
| 时间跨度 | 长期（持续演进） | 短期（项目周期） |
| 产出物 | 核心资产库 | 具体产品 |
| 变更频率 | 低（稳定为主） | 高（快速响应） |
| 决策权 | 架构决策 | 业务决策 |
我曾经在一个金融产品线项目里，看到过最理想的协同模式。领域工程组每两周发布一次核心资产的新版本，产品工程组则每周从资产库拉取最新版本，然后做自己的定制开发。
两边有一个「接口人」角色，专门负责沟通。领域工程的人会定期参加产品工程的迭代评审会，听听前线有什么新需求。产品工程的人也会参与领域工程的架构评审，确保资产库的方向是对的。
避坑指南：
我曾经见过一个团队，领域工程和产品工程完全隔离。领域工程闭门造车，产品工程自己另起炉灶。结果半年后，两边代码完全对不上，产品线工程彻底失败。
记住：没有反馈循环的领域工程，就是空中楼阁。
3.4 一个实际的协同流程
我建议采用这样的流程：
- 领域工程定义可变性点：比如支付方式支持「支付宝、微信、银行卡」，这就是一个可变性点。
- 产品工程提出需求：某个具体产品只需要「支付宝和微信」，不需要银行卡。
- 领域工程评估影响：这个需求是否影响核心资产库的稳定性？如果只是绑定选择，没问题。
- 产品工程做绑定：在配置文件中把「银行卡」这个选项去掉，然后构建产品。
- 反馈闭环：产品工程告诉领域工程，银行卡这个可变性点其实没人用，建议下个版本移除。
你看，这个流程里，两边各司其职，但又紧密配合。
核心原则总结：
- 领域工程不要替产品工程做决策
- 产品工程不要擅自修改核心资产
- 两者通过「可变性模型」进行契约式协作
- 定期同步，保持信息透明
嗯，说到这我想起一个细节。有一次产品工程组急着上线，想直接改核心资产库的代码。我拦住了。我说：「你改完这个产品是快了，但下个产品怎么办？其他产品线怎么办？」
后来我们建立了一个机制：产品工程如果要改核心资产，必须走变更请求流程，由领域工程评审。虽然多了一步，但长期来看，这步不能省。
好了，这一章就聊到这。下一章我们聊聊可变性建模的具体方法，那是个技术活。