构架是为什么人的

在软件项目中，我们一直非常强调构架，构架成为一个项目成功关键的因素。但是在很多项目中，我们的构架师有时会陷入很多迷惑，有时是设计不足以应付设计目标，造成系统的混乱，有时又过度设计，不但降低开发效率，而且导致系统运维艰难。加上目前不断有大师或厂家不断制造各种各样的构架泡沫，更让构架师和开发人员迷惑，所以，借伟人的一句讨论标题，我们也想讨论：构架是为什么人的？问题的本意也可以讨论成构架是为什么目标的，甚至可以说构架设计为什么？试图解开心中迷雾，如果能拨云见日，当倍感欣慰。

在一个软件项目的设计讨论会上，一个构架人员介绍完一个基于WCF的多层构架设计后，其他人开始提问题：

开发人员问：我们开发需要完成客户端功能和服务端功能，开发顺序是如何的？

构架人员答：因为是面向服务的构架，所以必须先完成服务端功能，再开发客户端。先有服务，后有界面

开发人员问：能否同时进行？因为构架已经设计好了实体对象或接口，客户端可以直接拿来用，完成以后再去连服务端不可以吗？

构架人员答：不可以同时进行！因为构架设计好的实体对象或接口是服务端的，服务可能会暴露出一部分属性，而不是全部，这是安全所必须的。客户端必须根据服务端暴露的属性，通过代理的方式访问服务端。

开发人员问：那客户端如何重用呢？当服务端因为安全因素改变了一些属性，客户端岂不是又要推翻重来吗？

构架人员答：这就是SOA，以服务为核心，一切都是围绕服务进行的。

开发人员问：目前这个项目需要100个实体对象，8000个业务，都要这样做吗？以前直连数据库，需要6个月完成，后来用3层结构，4～5个月可以完成，现在要面向服务，需要几个月完成？可以有自动化生成代码吗？系统采用了这样的构架，运行时的性能会降低多少？

构架人员答：的确都要分层处理，不过可以自动化代码，但是因为很多不定因素，所以仍然要手写大量代码。开发时间估计大概是比以前的要长，估计6～8个月完成。

而系统的性能，也会降低很多，具体数据还有待考证。

开发人员问：我们想知道使用WCF的必要性，这个特性有必要牺牲这么多效率和性能吗？

设计人员也问：我们设计的界面，可能会需要建立一些新实体的支持，这些也需要服务端来完成吗？

构架人员答：SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。可复用以往的信息化软件。基于SOA的协同软件提供了应用集成功能，能够将ERP、CRM、HR等异构系统的数据集成....

 

系统构架是决定系统构成的一系列结构、方法和过程。我们这里讨论的构架，是指可以在现在和将来在实践中真正运行的构架。

构架可以在学术和理论层面高屋建瓴，甚至虚无飘渺，但是在具体实践中，构架一定是可以使用的技术，是一系列从实践中来，经过系统化整理反过来指导实践的技术。系统构架不同于建筑构架，不是作为表演、娱乐、欣赏的艺术，也不是作为祭祀、迷信和顶礼膜拜的符号，也不是载入史册、万古流芳的私有专利。既然是实用技术，就一定是务实的，而不是虚幻的，否则，不但不能在实践中发挥指导作用，甚至阻碍实践进行。所以，实用主义一定是构架的指导思想。

构架既然是为实践服务的实用技术，就是为实践的每一个环节提供良好的设想，以保障实践的过程是高效而合理的。

在具体的项目中，构架设计就是为了软件项目在系统目标（需求和使用者），系统结构，运行设备，设计工具，开发工具，开发方法，开发人员，开发过程等因素上达到完美统一而进行的一个预先活动，目的是根据已有资源，适当成本，完成高质量的项目。

构架是为什么人服务的？从整体上，是为系统服务的；从具体上讲，就是为这些目标，为设计人员和开发人员，以及开发和运营过程服务的。

项目中的目标，是由项目中的参与者完成的，这些人员包括设计人员、开发人员、测试人员、部署、培训人员等等，所以，他们是构架设计的实施者，他们的理解用户需求，正确完成用户需求，高效开发代码和并经过多次测试，完成高质量系统，他们的成功，才是项目的最后成功。

构架服务于系统需求，首先要服务于我们的项目人员，就是这些不同阶段，不同层面的设计和开发人员。只有通过他们，我们的项目目标，我们的客户，我们的系统使用者才能够得到他们想要的结果，也才是项目的成功。虽然，用户单位可能也会对构架部分有一些设想和需求，但比较业务需求来说，构架对于用户单位和他们的使用者，仅占很少的部分。只有我们的自己的软件工程人员，才是构架的最重要的用户，才是构架的受益者。如果一个构架不能给他们提供方便，提供正确的指导和帮助，而是制造障碍，层层设堵，那么损害最大的是我们的开发人员，然后是他们服务的用户，然后是应用构架的这个项目，再后是我们的公司，最后可能就是构架人员自己了。

所以，如果一个构架给开发和设计人员带来的如果不是工作效率的提升，而是效率的降低，开发方式的繁杂，测试方法的复杂，即使在其他方面带来巨大的益处，都不足以降低开发效率降低所带来的项目失败的风险。

具体说，松耦合是对的，面向服务是对的，但是，一个新的构架不能仅仅建立新的方法，而老的方法和遗留的系统统统抛弃。如果这样，新的技术和方法终会因为考虑不周而陷入僵局，最后不了了之，最后无人问津。一些风光一时的新技术新方法最后归于沉寂的实施都在不断证实这样的道理。一个构架失败，带来无数项目的无药可就，构架的鼓吹者不会负任何责任，只有构架设计和项目小组的人会为此付出惨重代价。

我们并不反对构架人员采用新的构架和方法。我们是反对不求甚解，一味追求新构架，在没有理解新构架的精髓之前，在没有找到弥补新构架的缺点之前，可以先暂时等待观察一段时间，要么自己解决问题，要么等待别人解决问题。问题终归是问题，需要解决后才能使用，不能解决问题的构架自然是不能用的，用了就会给其他开发人员造成损伤，不负责任带来的后果就是失败。

我们也反对有些构架人员以构架为大旗，搞迷信和膜拜，将构架神化后，自己从中受益。别人问到构架的问题，不能自圆其说，还态度蛮横，一副构架就是金枝玉叶的架势，一副老虎屁股摸不得的架势。这种受益的结果只能是害人害己，最后一无所成。

 

了解了我们的构架是为什么人的，就应该切实贯彻这样的思想，从构架的最初，就首先想到我们的开发人员，然后才是新技术，新方法。适合的而没有问题的构架，可以采纳；适合的有问题的构架，需要解决问题后采纳；不适合的以及问题太多的构架，抛弃。

有了真正的服务意识，我们的构架可以想出很多好的方法解决开发效率、测试效率等问题。如多层框架、面向服务构架带来的开发效率降低问题，可以采用开发时采用传统C/S方式开发，而部署时可以部署成多层构架或SOA构架。这样，省去了多次写相同或类似的代码的多层开发方式，松耦合带来的好处立杆见影，带来了良好的效果。设计人员只关注业务需求和业务层、表现层，开发人员仅根据设计建立良好的表现和业务，而不必关注系统有几层，每层需要如何连接，如何单元测试等问题；而测试人员也仅仅只对业务测试就可以完成大部分测试工作，而不必为每一层建立测试用例环境，甚至无法进行测试。这种方便各个层面的新构架设计，使开发人员和设计人员都很愿意接受，这样的构架才是正确的构架方向。

在这里，了解构架为什么的同时，我们提到了很多受人追捧的构架，并且很多财大气粗的软件厂商都在不断推进这些构架，这当然是他们的战略方式。如果他们真正理解构架，理解构架是为开发人员而不是最终用户，他们可能就不必让最终用户了解什么是构架，将更多的资源放在设身处地为开发人员考虑，将下一代的开发模型真的更加适合设计人员和开发人员，而不是增加他们负担。

这里，仅仅就问题的讨论，提到了SOA，提到了云计算，提到了多层构架，其实，这中间的混乱也是有目共睹的，哪个是真正的核心，哪个仅仅是一个手段，哪个是一个中间技术，哪个是方法论，哪个是实用技术和工具，哪个1年后还在提而5年后就找不到了，哪个5年后还在提而且要一直持续下去...

这些都是我们讨论的话题，也是构架为什么的一部分。