所以软件工程的发展趋势是组合拳。
这个模型重点就是属于敏捷，有的时候大家就是在整个产品集做出来之后，对这个功能规划提出来之后，就在这功能里边打开，然后就把这功能里边罗列出来，然后就开始计划后开始快速迭代。
尤其的好的传统企业做敏捷做的不太到位的时候，就就记住这一个速度，就看中了这个两到四周的速度，其实对这个过程来讲是不完整的，也是有缺陷的，那么敏捷过程来讲，其实在这儿在这儿它稍微有一点弱项，因为他没有给出一个好的有列控能力点的方法，他主张的是头脑风暴，大家在一块儿快速讲，反正他第一版那个东西做得有缺陷也没事。我可以后边留一把这缺陷补充。
就是说这块儿其实缺少一个扎实的方法。所以有人提出了DDD领域驱动开发，提的这种设计方式他认为跟敏捷很配。因为他这个方式其实对于做其实他也算是分期的方法，那么这种方法你觉得操作性的速度的，如果做的熟练的情况，操作起来速度确实很快，而且隔开，而且跟后面设计的直接对应，所以他确实能解决这个层面。
但这个方式一开始出来的时候不是太好理解，所以技术人员并没有把它拿起来用，就是没有一开始就让那个敏捷配上，这到什么时候呢？到这个后边这个微服务架构出现之后，这个微服务架构出现之后，大家就会服务确实挺好，整个上线速度挺快，跟敏捷开发是被说这块代码写的快，这边部署也快。
嗯，但这就有一个问题，就是大家也都知道啊，这个微服务，问题就是多大的服务叫微服务，什么叫微服务，我们怎么切分企业的服务，就是这时候大家又想起来说，那是不是可以再走一走的这个层面。那么有人又专门去写着怎么用给你一种方式DDD来设计为微服务，所以就这几种方向之间是可以组合在一起去共同来提升这个软件开发速度。
虽然是一个组合拳吧，就是敏捷方法，就用的是过程管理，然后DDD注重的是产品的架构设计，然后微服务是支撑他这个实践。
那这块我们也看到了一个趋势，就是刚才我们说从软件架构到企业架构，这是一个架构发展的趋势。另外一个趋势就是出现这种架构方法之间的组合是，大家越来越觉得说一个方法去把他填一下，不一定合适。你能大一统的方法不一定合适，那么我们可以发了各种方法的优势，各种方法结合起来，解决我们面对的种种复杂问题，那么最终组合拳，就是现在有一种例子，其实我个人觉得这种这种方式本身也非常好。
而且做方法论呢其实你也需要有这种态度，方法论上的不是用来吵架了，做方法论了，其实最重要的是给你一条主线，去吸收别人的优秀经验和你自己的经验，方法论之间互相之间并不是排斥，它只是给你一种吸收经验的指导。
这个工程刚才咱们说敏捷那一块的工程发展呢，如火如荼的，但是这个就是咱们是传统的一个笨重的架构领域啊，这个架构领域后边相对就慢了一些。
在这里讲一下DoDAF的，这个架构这种总结起来，其实主要就是他用换了一个视角去看架构这个问题，就是说他不太限制软件上设计。他关注的是什么呢？关注的是信息，就是数据。它强调说用体系结构数据取代体系结构产品就是做出一套类似于数据模型的东西。
那么上面我们就是简单回顾了一下这个软件工程和软件架构的一个发展过程。
企业级业务架构方法论的介绍
关于数字化，砸烟囱，复用，双模开发，减低成本，企业转型这些困难，我们是否可以找到一个共同的发力点来解决这些问题呢？那咱们做计算机的一直有这种抽象思维，在不同的问题里面找到共性的东西，那咱们可以挑一个发力点，通过问题的解决，让咱们的问题都有一个好的解决方法，为一些问题的解决提供一些支撑，那么这个问题我们又回到了企业的发力点上，做企业就要关注企业管理，那么我们这个找到所有问题的共同点，那其实就是提高企业的整体性。
