在领域驱动设计（Domain-Driven Design, DDD）中，面对业务需求的不断变化，设计领域模型以支持快速迭代和变更，同时减少对现有系统的影响，主要可以从以下几个方面入手：

1. 明确界限上下文（Bounded Contexts） 明确界定了系统各个部分的边界，可以帮助我们更好地隔离变化。当业务需求发生变化时，我们可以针对受到影响的特定上下文进行调整，而不会对系统的其他部分造成广泛的影响。例如，假设一个电商平台需要在结算流程中新增一个支付渠道，我们可以在‘结算’这一界限上下文中进行相应调整，而不是对整个平台进行大规模改动。

2. 保持领域模型与业务对齐 当业务规则发生变化时，应该快速反映到领域模型中，确保模型始终正确反映当前的业务需求。这要求开发团队和业务团队之间保持紧密的沟通，确保任何业务变化都能被快速地识别并转化为技术上的调整。例如，如果业务上决定对某些商品实施更加灵活的价格策略，那么领域模型中就需要及时引入或调整‘优惠’、‘促销’等实体或服务。

3. 使用事件驱动架构 通过引入事件驱动的设计模式，可以使系统组件之间的耦合程度降低，各组件只需要关注自己产生的事件以及订阅到的事件即可。这样，当其中一个组件需要调整以适应新的业务需求时，可以尽量减小对其他组件的影响。比如，订单服务产生了一个订单创建成功的事件，库存服务订阅了这个事件并在收到后自动减少相应商品的库存。

4. 采用微服务架构 微服务架构自然地支持了多个小型、自治的服务，每个服务专注于单一的业务能力。这样当业务需求发生变化时，通常只需要修改特定的服务而不是整个大型单体应用。例如，在网上银行应用中，如果需要改变转账功能的实现，那么只要对转账相关的微服务进行迭代，而不必改动整个银行系统的代码。

5. 持续重构与优化领域模型 对于已经存在的领域模型，应该持续进行审查和优化，包括但不限于拆分过于庞大的聚合、合并功能类似的领域对象、优化领域事件的触发逻辑等，以保持整个系统架构的健壮性和可伸缩性。随着项目的进展，最初定义的领域模型可能不再完全符合现在的业务需求，定期的重构有助于维持模型与业务的一致性。

6. 坚持最小化服务接口的设计原则 设计微服务时应尽量减少服务之间的直接调用，转而更多地利用业务事件进行通信。这样可以减少服务之间的依赖度，使得系统更容易适应变化。例如，避免在账户服务中直接调用订单服务来查询订单状态，而是由订单服务发布订单状态变更的事件，由账户服务监听并作出相应反应。

总之，通过以上策略的应用，可以有效提高领域驱动设计在面对不断变化的业务需求时的灵活性和响应速度，同时降低变更对现有系统的负面影响。