IT餐馆—第十四回 架构

老杜听雨辰这么说：“行，大概情况摸清了。到时有什么问题再打电话沟通吧。看来你们这个产品是使用三层架构方式了，呵呵。不过你们想没像将来会不会随着业务模型的日趋细化完善，产品功能的多样性所导致的业务逻辑层不断扩充。最后会不会造成业务逻辑层越搞越复杂呀。”

雨辰笑了笑说：“这个问题的确考虑过了，目前我们就遇到了类似的一些问题，比如我们的产品在去年加入了空间和相册功能，当时是采用了新建项目的方式来将其引入到解决方案当中，而这些新增功能都是直接引用了业务逻辑层的dll。后来考虑到有些用户可能不太乐于使用这两个功能，所以我们就又改成了‘插件’的设计方式，使之受制于后台‘开关’设置，只有开启插件功能并检查相应插件DLL是否有效后，插件才会启用。这样就把业务逻辑层扩展到相应的新增功能的‘业务逻辑层’（空间相册也有相应的业务逻辑层）中，并进行插件接口级别的定义扩展了。另外，继FACEBOOK开放API之后，‘开放API’成了时髦话题，所以我们不可避免的遇到了这个问题。刚才我说过，这次重构业务逻辑层的‘标准’之一就是让其方法适合于以API方式进行‘暴露’，而API只要直接调用或简单组合其中一些方法就可以完成一个业务流程或实现一个新的业务（组合实现）。这有点像是模式中的FAÇADE，其对外提供了统一访问的接口，而不必关心子系统（业务逻辑系统）内的复杂实现。”

老杜：“听你刚才说的组合业务逻辑以创建一个新的业务，怎么听起来有点像SOA呀！”

雨辰叹了口气，接着说：“我们的产品目前还做不到SOA那样的高度，必定那是以企业级市场为主，以可复用、可配置、元数据驱动、服务自治为原则，快速响应业务等为导向的。我们的产品主要是面向互联网的站长，他们的业务需求比较稳定（对于业务的差异性可通过二次开发满足）。而产品中的模块，方法之间耦合性比较高，尽管我们努力遵循‘高内聚、松耦合’的设计原则，但多数方法的使用还是被业务流程紧耦在了一起，往往这个方法只在当前业务流程中使用，放到别的流程中就很难采纳了。而要提高模块的通用性，就要求‘与业务逻辑关联’越少越好，分割出来的方法必定会越来越多（分解粒度细），而其方法内部代码则越来越少。导致等到在业务流程上组合这些代码时会造成调用比较繁复，细节上的东西暴露的过于繁杂，‘想和不想’暴露出来的东西都被放出来，阅读起来也会有‘心晕脑胀’的感觉，不利于通过看代码抓住‘业务核心’。我想这应该是一个原因吧，必竟我们要在这些互相影响，甚至‘对抗’的设计思想之中找到一个‘平衡点’。但我们并不确保将来随着业务的多样性，平台（包括异构平台）之间的整合、互操作以及模块、组件‘可复用性及复合的需求’不断高涨的可能性。真要有那么一天，到时可能会参考SOA及其它一些架构方法的设计原则。呵呵。”

老杜：“不错，我比较烦感那些鼓吹这个架构，那个模式的软件，动不动就搞什么soa，也不管适不适合自己的项目和产品。必定产品是为了满足用户需求，如把架构和模式放在第一，那并不是王道。必定国内以技术为主导的公司少，即使有的话，生存状况也未必尽如人意，而大多数还是业务为主嘛。架构要符合自己公司的自身情况，能够最大限度的满足业务需求就可以了，那怕你架构出来了一个‘四不像’，我想都是可以接受的，管它什么soa、还是使用什么DDD,TDD,FDD方法呢，谁在乎呀。不过最近asp.net MVC模架很火，不知道你们想没想过？！”

雨辰笑着说：“当然也在想了，打它推出beta版时我就一直观注着呢！只不过在正式版发布后，正好我们的产品正在进行重构，一时还真没有太多精力抽时间来研究它。不过其设计初衷还是很不错的，之前看过一些它的源码，基本上所有的功能特性都是可扩展的。这也给我们产品的‘接口设计’提供了一些‘有益的参考’。其实我个人认为从三层架构迁移到asp.net MVC开发方式上‘主要的问题’还是‘需求’上，而架构上并不会有什么太大阻力。必定都是微软的东西，过渡上不该有什么太大问题。”

雨辰说着就打开了一个带有mvc架构图的PPT文档，指着图中的view对老杜说：“这个PPT是我之前给公司同事做培训时使用的。其中：

MVC架构图中的View对应的就是之前我们所使用的模版或aspx页面上的代码。

Controller则对应相应的’aspx.cs’文件，该文件下实现页面数据绑定和跳转，与Asp.net MVC框架中都有相应方法对应。

如果我们的产品要支持asp.net MVC的话，那model层（域模型）就是我们的‘数据访问层+业务逻辑层’，今天先不讨论业务逻辑到底该不该放在model中，必定领域模型中关于这个问题有着不同的看法，这里只假设使用贫血模型。我们通过数据访问接口将获取的数据绑定到相应的对象或对象集合中。另外我们会继续使用现有的业务逻辑层代码。我把迁移分为三个阶段：

1.将模版页中的逻辑迁移到mvc框架中的viewpage。

2.然后将.aspx.cs文件转到相应的controller的actiion方法中。”

3.对原有的httpmodel的urlrewrite方式换成mvc中的URL Routing方式。

这样，其它层和项目的代码可以保持不变，迁移就大功告成了。”

听着雨辰滔滔不绝的说着，老杜对比MVC架构图和头脑中的三层架构模型，不断的来回切换着。

最后听雨辰讲完了之后，老杜点了点头说：“看来你是想到我前头了。之前我也在考虑这两种设计的切换问题。必定微软这次给出了一个除了WebForm开发模式之外的选项，尽管之前有monorail打了那些年的头阵，但这次由微软亲自操刀推出的框架必定‘非同小可’，相信除了技术层面，还有不少技术之外的因素在里面。网上也有不少人谈过MVC架构上的问题，但基本上都是从该框架中的技术层面来谈问题，其它这些在我看来都是门面功夫，真正有价值的还是业务逻辑层里的东西。这里面的代码才是公司和企业多年积累的‘真金白银’。”

雨辰听老杜这么说，也感慨的说道：“其实你所说的‘业务逻辑层’在微软的‘模式与实践小组’的Service Layer Guidelines中就已被‘定稿’了。在它官方文档中就特别提出将业务逻辑(层)单抽出来，并提供一个应用外观（applicationfacade）进行封装，不仅如此，对外发布时，以‘服务’的方式进行‘暴露’。这种发布方式颇有soa的味道。”说着，雨辰把该文章的链接和架构截图地址传给了老杜。

雨辰接着意味深长的说：“其实这些年在网上看了不少有关框架，架构的文章。而象nhibernate,spring.net,aspect#,castle的源码也看了。总体感觉这些框架作为学习资料还是挺有帮助的，可以扩展自己解决问题的思路。只不过目前在国内真正用起来的还不是很多，至少我没见过身边的同事在实际开发中使用过，可能我这些年一直在中小公司呆着的原因吧，所接触到和使用的都是‘如何快速开发完成任务的项目’，只是到目前这家公司才开始正式做产品，但也没有真正使用这些框架。也许将来到大公司做大项目时才能用上。呵呵。不过有关于三层架构方面的东西到是有用的，这必定是一个经典的架构模式。”

老杜呵呵笑着说：“其实软件设计的三层架构只是一个基础，通过它，就可以不断扩展并掌握N层架构的设计思路。你之前所说的业务逻辑层重构，而具我所知道的情况，这一层如果在软件的业务上不断复杂化后，就可以在此基础上，不断扩展出新的‘层’，只要业务逻辑允许，便于重用、测试，就可以细分下去。我之前在公司里作产品时就把这个业务逻辑层又分出了几层，分别是业务组件层，核心业务逻辑层和辅助逻辑层，外观层。与你之前所说的那个微软所提倡的架构模式有些相似，但又不完全相同。不过我相信我这种划分是适合我们的产品的。这是往多了分层，还有往少了分的，比如将业务逻辑层和数据访问层合起来的。甚至如果业务很简单，要求1周完活的项目，用户只要求快，其它的问题他都可以担待，这时将sql语句写到前台页面中都有，那样就成了‘不分层’或‘一层’架构了，尽管这样会造成层次不清晰，各层代码杂居到了一起并导致可复用性差（尽管复用需求不高），呵呵，不过我想说，分层要具体问题具体分析，别动不动就给自己下硬指标，那样只能是‘自己下套拌自己’了。对了，架构这个工作在一些公司专门有架构师这一岗位的，只不过国内的不少公司都是把架构师理解为高级程序员或资深工程师。”

雨辰听了老杜说架构师的事，来了兴趣说：“不过在国内有实力的大公司对架构师这一职位要求是很细的，比如从业务和技术这两方面就有业务架构师和技术架构师，比如我之前看阿里巴巴的一则关于业务架构师的招聘信息，里面就有这么两条：

1、参与或负责数据产品规划、研发，为网站提供以数据为支撑的业务产品规划方案；

2、建立业务逻辑分析模型，改善、支持、推进产品在网站中的实施，为用户、网站提供更多更好的以数据为支撑的产品服务。

而我们开发者对架构师的理解多是从技术角度出发的，动不动就是什么框架，模式，DDD,TDD之类的，相信你在网上也看了不少那方面的信息。不过就目前来看，国内很多公司把这两方面的要求给‘合并’了，导致架构师即要懂业务又要精通技术。说实在的，能把这两方面都抓好的人，我没碰到过。大多数我遇到过的架构师都是偏技术的，懂业务的太少，能把公司业务与技术完美结合的更是少之又少。最惨的是挂着架构师的职位，业务、技术都不精，只因在公司里他的人缘或技术说的过去，所以领导就‘矬子里拔将军’了。其本身的能力放到业界‘冲其量’要么只是个业务人员，要么是个程序员而已。另外就是其实从业务和技术的角度来划分的不仅限于架构师，还有业务经理、技术经理等级别的。小公司因为人员有限，起步时肯定是一人身兼多职，我认识的一个辞职创业的同事就是又当老板又开发，当工资发不出来时，还要到外面去接私活，以及扮演‘讨债’的角色，你说累不累，呵呵。”

雨辰接着说：“另外拿我所在的这家公司来说吧，基本上就没有架构师这个岗位。而架构方面的问题都是通过资深产品工程师和高级工程师来兼做的。因为我们公司以开发产品为主，采用产品经理负责制，我们的产品经理的权力大的很，管的事也多，从业务需求到产品开发、解决核心问题、测试、上线推广宣传、代码维护、修正BUG等方方面面。不过我的感觉是一个人的经历必定有限，能穷其精力做的事也就那么几件，所以这种方式未必就好到那里去。不过在公司现金牛产品上，往往有多个产品经理共同把关，这时按我的理解就分为了业务产品经理，技术产品经理，市场产品经理了。这几个人各抓一摊，统统听命于老板。”

……
两人就这么又聊了一会儿，这时雨辰看了看时间差不多了，正巧老杜也有事，就相互寒暄了几句之后，送老杜离开了公司。

原文链接: http://www.cnblogs.com/daizhj/archive/2009/08/17/1541395.html

作者: daizhj, 代震军

Tags: IT餐馆,架构

网址: http://daizhj.cnblogs.com/