事件溯源股票投资组合应用：命令处理的股价获取方式问询

针对你提到的股票及投资组合管理应用，关于BuyStocks/SellStocks/ClosePortfolio命令的股价来源问题，两种方案各有优劣，核心要围绕事件溯源的可重现性和事实记录完整性来权衡：

方案1：从API的DTO接收股价 #

优势 #

• 确保事件可重现：事件溯源的核心是通过重放事件重建系统状态，如果命令里包含交易时的实际股价，重放时不需要依赖外部价格服务，完全基于原始命令数据就能还原出和历史一致的投资组合状态，不会因为外部服务的历史数据丢失、价格修正等问题导致状态偏差。
• 命令自包含，边界清晰：命令本身就是用户操作意图的完整记录（包括用户确认的交易价格），事件溯源核心只需要处理命令内的数据，不需要耦合外部服务，降低了核心逻辑的复杂度。
• 符合事件溯源的事实记录原则：事件要记录的是实际发生的业务事实——用户是基于某个特定价格完成的交易，这个价格就是事实的一部分，应该被永久记录在事件中。

潜在问题与解决 #

• 存在用户篡改价格的风险：可以在API层增加校验逻辑，调用可信的实时价格服务，验证用户传入的价格是否在合理波动范围内（比如允许±0.5%的误差），校验通过后再将命令传入核心层。

方案2：服务组件获取股价后传入核心 #

优势 #

• 价格权威性有保障：直接从官方价格服务拉取数据，避免用户传入错误或恶意价格，省去了API层的价格校验步骤。
• API DTO更简洁：用户只需要提交股票代码、交易数量等核心信息，不需要关心价格字段。

劣势 #

• 重放事件时的一致性风险：如果后续重放事件时，价格服务的历史数据无法获取，或者原始交易的价格被回溯修正，重放得到的投资组合状态会和真实历史状态不一致，违背了事件溯源的核心价值。
• 命令处理依赖外部服务：核心逻辑处理命令时需要调用外部服务，增加了异常处理的复杂度（比如超时、服务不可用），甚至需要引入重试、补偿机制，降低了系统的稳定性。
• 事件记录的事实不完整：事件中记录的价格是服务事后拉取的，并非用户操作时触发交易的那个价格，无法准确还原当时的业务场景。

推荐方案 #

优先选择从API DTO接收股价，同时在API层增加价格校验环节：

1. 用户提交交易命令时，同时传入前端展示的实时股价；
2. API层调用可信的价格服务获取当前实时价格，验证用户传入的价格是否在合理误差范围内；
3. 校验通过后，将包含股价的命令传入事件溯源核心，核心处理后生成包含交易价格的事件（如StocksBought、StocksSold）。

这种方式既保证了事件的可重现性和事实完整性，又规避了用户恶意篡改价格的风险，同时维持了核心逻辑的独立性。

内容的提问来源于stack exchange，提问作者riccardo.cardin