领域是软件要解决的问题，系统是已有的系统。it系统上了一定规模的企业，尤其是现在具备一定历史的互联网企业，都坐拥大量系统，业务就跑在这些系统上。很多企业的开发团队都按系统划分，甚至有大量的团队主要工作就是实现系统的新需求。
这种状况限制了开发人员的思考空间，也带偏了需求设计人员的方向，最终一个个企业都倒在自己的软件资产上。
当你听到需求讨论充斥这xx系统调xx系统，xx系统写个xx数据，你可以立即断定这个需求很大程度上受系统现状的约束，顺便满足一下客户的一些需求。这种做系统的方式我叫他系统驱动。即便也采用敏捷的一些工具和方法，但这一定是一个个的小瀑布。
领域驱动的做法于此相反，在需求讨论中一定围绕客户和业务，通过对业务的理解和建模，再映射到现有系统的重构。
