DDD这种开发方法论已经关注几年了，也是想把这种先进的方法论融合在开发过程当中。但这种开发方法论在在这种企业、政府的大型软件开发过程中，总感到向banq老师的一幅图一样悬在空中，无法真正去实际操作。
最主要的问题有两个，一个是人才，一个是开发。
在这种大型软件开发过程中，首先一个项目是几十个人进行协同工作，由于招聘的难度，培养的难度，能够保持一个核心团队有这样扎实的思想就已经很不错了。我认为通过需求直接画领域模型，这件事对大部分人来说难度还是太高。能否将DDD这种思想的台阶降低，或者有一个可控的过程（由扎实的思想的人去评审等）？
DDD能够把业务分析的很透彻，这大家都知道。在开发方面，与实体交互的已经讨论很多了，但是如何与页面交互，与其他系统交互，比如工作流，权限等等。这些如何用DDD思想去分析？
请banq老师和各位道友帮忙解惑。
DDD附注为复杂软件系统的使用，所以，如果你的系统只是一些增删改查，就确实没有必要使用DDD，这也是看上去DDD使用很少原因。另外也和人才有关，以及管理者是否认识到DDD好处，以及要求以DDD方法实践复杂的大的产品，这需要一个过程。
目前DDD是普及推广阶段。
企业、政府的大型软件可不都是增删改查。他们的核心业务都是非常复杂的（可能跟国情有关系），而且政策，环境的变化会导致业务不停的变化，程序也在不停的改动。一个软件的生命周期会在这不停的变化中急速缩短。为了延长软件的生命周期，才会希望有DDD这样能够透澈分析业务，甚至能够分析出隐藏业务的方法论去解决。
在公司开发过程中职责分配已经是分析阶段转换到设计阶段的一个重要的手段了。DDD也在业务建模的过程中也应用了一小部分（算一种DDD的变形吧）。但是盘点整个开发过程，DDD的比重还是太少。所以经常还会出现，实现的程序业务不是客户想要的，虽然这种情况已经减少了。
根据banq老师的回答，我感觉DDD使用很少的原因可能是多方面的。
也希望j道能够在DDD的普及推广过程中，不断完善DDD使其能够适应中国国情，形成j道自己的方法论。
不错，DDD追求统一语言，可以减少中间环节增加带来的失真，如果还出现不一致，脱离需求，我看问题可能在模型是否中看不中用，建模是一个多角度看同一个事物的过程，这个思维培养不是一天两天，比如在案件审理辩护过程中，对同一个证据或现象控方和辩方有不同的理解，甚至完全相反，两者都可以形成一个自圆其说的闭环，那么哪一个认识是最本质的呢？最接近事物内部规律呢？
我认为软件建模和案件审理一样，都是需要高度抽象思维能力的，并且从 不同角度来认识事物，试图找到本质规律，当然，说得好听一点，这些都是人类最高级的活动，说不好听，是最累人的活。所以，国外律师报酬最高，建模师也很高，国内由于很多人思维都达不到认识到这个高度的能力。所以，对这两个行业都不以为然。路很长，在于开智啊。