软件烂尾的原因有很多种，比如，需求反复修改导致开发过程极不顺畅，一点小的改动就牵扯一大片，越改问题越多；比如客户过分追求低价或者开发公司为了接单过于价格竞争，最终开发人员只能用降低开发质量、偷工减料等来节省成本，也比如，客户过分追求软件功能的大而全，使得项目复杂程度很高，普通开发团队无法很好的应对等等，这些都为项目烂尾埋下了隐患。
当然，像资金断裂、团队分裂等外力原因导致的烂尾我们在这里就不做讨论了。
其实绝大多数项目都是使用的成熟技术，烂尾都不是因为技术复杂，而是因为开发人员对业务理解不到位，或者是不同的开发人员对同一个业务采取不同的抽象方式，在项目早期就埋下了逻辑冲突的种子，随着项目的进行，这种不一致影响到大部分功能点，就像病毒已经感染了大多数人，这时要修补涉及面非常广，还不如重做。
深度理解需求
我想大多数人都会同意，改需求是软件开发中最头疼的事，不仅会遭遇技术团队的抵制，而且改来改去轻则导致代码难以维护使项目失去迭代的生命力，甚至导致项目烂尾。领域建模解决这一痛点的核心理念是运用辩证思想，将易变的代码与稳定的代码分开，简称“分离变与不变”。
我们在软件开发前期引入领域建模，采用技术建模和概念建模的方法，让团队可以更好地理解业务领域和相关需求。可以避免在项目开始时对客户需求的理解模糊或误解，从而减少在开发过程中出现的客户进行需求变更和调整的行为。
融合产品和技术
现实中，产品与技术的争吵确实是家常便饭，一个功能，产品经理看起来很简单，但技术人员却硬说做不了，气不气人！其实双方都没错，问题的根源还是在于领域模型的不一致。可能双方都没有进行正式的建模，但是在他们的头脑中都是有模型的，产品经理基于模型设计原型，技术人员基于模型编写代码，但是双方头脑中的模型不一致，因此产生了深层次的冲突。
我们主张在项目早期开展统一的建模工作，首先构建概念模型。产品经理基于概念模型设计原型；技术团队经由技术建模形成领域模型，然后以它为基础进行后续的应用层开发，减少产品和技术发生冲突的概率，提高团队协作。
