领域模型拆分

请教大家一个业务中遇到的问题：
当你对一个领域（如供应链系统中的供应商）进行了分析、建模并构建好系统之后，突然由于业务上的原因，这个领域转变成了两个，不管是业务对象还是业务流程都已经分离开了，剩下的只是一小部分交叉的数据，这时该如何处理？
貌似DDD从未注意到领域也不是一成不变的。

此种情况不可能发生

没有看明白lz的情况， 能否描述的详细些，
为什么拆分，拆分的主要方式，结果。
领域模型，合并与拆分都是可能的。

以前的模式是我们向供应商采购货物转售，配套的系统是采购、收货、库存管理、退货（用户到我们，我们到供应商）、结算
现在一部分供应商变为我们平台上的独立销售商，我们仅提供库存管理（如果他们使用我们的仓库），其它大部分都由销售商自己管理（但是是使用我们的系统，这套系统需要我们新增）
现在的问题就是新老系统从领域设计的角度出发应该如何做得更好？
还有一个潜在的问题就是，这些独立销售商往往是在我们平台上业绩表现不是很好的供应商，所以我们把他们独立出去发挥“责任田”功效^_^
所以，在以后这些销售商做大做强后，可能咱们又会把它们“强制”转回供应商，走旧的流程
期待你的建议，谢谢

你们对渠道采购和分销业务缺乏经验，领域模型如果仅基于现有业务来进行分析建模，结果就是这样。这个不是领域模型拆分，而是重新建模，DDD解决不了你们业务不成熟的问题。

碰到业务发生重大变更，系统也要走变更，只是变更的工作量有多大而已，即使你建了一个很完善的领域模型，也只是能使系统变更能平滑一些，并不表示系统的变更就那么简单。

业务不成熟是一个方面，但另一个方面是业务本身就是需要不断创新的，流程优化和再造工程已经成了一个专有的部门并被高度重视。
我注意到这些变更在脱离软件系统的情况下会很快实施，但系统的转变就很难了。
DDD是贴近真实业务世界的一个进步，细化一下粒度也许能更容易地改变系统，但这种思想可能还需要升华
大概只有深入地了解业务变更过程中真实的企业组织如何去实施这些变化，我们才能进行新一轮对软件系统的映射

我简单理解楼主的意思:
原来的软件模型以及产品匹配了的业务，现在因为各种业务创新，而增加了许多业务模式。

如何让现有软件系统来适应这种改变。

是重构现有系统？
还是重新建立新模块，匹配新增业务？

另外，还看得出楼主想从根本上解决这个问题，想从问题的源头来思考问题的本质。


对于这个大家不可避免的问题，
我建议楼主考虑集成。

新业务就是新业务，新业务需要新系统支持。
然后考虑将对应多个业务的多个个系统集成。

这样即时再有新的业务模式创新，我们需要做的就是新增可集成的子系统。
而不必太过关注于业务对应的组织结构，以及挖掘后期可能变更的东西。

因为，我们终究是软件研发人员。