DDD：一个朋友对领域驱动的小结

首先我在一家老板有点关系的小软件公司带领一帮工作一两年的程序员做项目，这里要特别强调的是做项目(差不多是外包，只不过客户群体比较固定)，项目就是今天项目A是这个逻辑，明天项目B是那个逻辑，两者之间的业务基本没有什么可复用的地方。 在这种项目上实施ddd，感觉非常痛苦，比传统的开发模式要花费更多的成本。举个简单的例子，对一条信息进行编辑， 用ddd的话，可能要经过3-4次的对相同内容的赋值操作，尤其是在引入领域事件驱动的情况下更是如此。而传统开发模式可能就一次赋值就提交到数据库中，尤其是这些项目的90%的功能都是基本的CRUD。所以我觉得这种没有很大持续性的项目(就是几个月做完验收后,可能再也不会打开这个项目了)采用DDD，就是给自己找麻烦，更别说在这种项目上去推广ddd，去说服别人用ddd了。 那到底什么时候用DDD，我现在有个项目是要做一个平台的服务，如果项目进展顺利可能要持久好几年，甚至一直做下去，这种项目即使对CRUD采用了DDD增加了成本,但是由于项目名是有持久性的，所以这种成本我感觉就很划得来。所以我对什么项目用DDD的想法是，需要持续性开发维护，生命周期长项目本身会逐渐成长的企业级应用，我想在这样的项目上使用DDD一定能感觉到优势。