企业应用架构的设计--是面面俱到还是仅仅提供基础服务

有2种思路。

一种是尽可能地将能隐藏的东西隐藏起来，将能封装的功能封装起来，提供给developer的只是一些傻瓜级的API。程序员可发挥的空间很小，比如甚至都不需要知道数据库表。

另外一种是选择好合适的技术架构，做好基础设施的搭建，比如异常处理，权限，工作流。只提供简单的封装，程序员有足够的灵活度。

显然，前者的情况，程序员会比较没有动力。优势是系统的核心程序员无法触及，相对安全。有不少公司都是这种情况，程序员的流动性相当高，不过老板也不在乎。

而后者的情况，程序员会有较高的积极性，容易成长，团队的融合会比较不错。更加符合敏捷的思路。但也许产品或者项目的规模大了后，会导致失去控制。

也许还是应该具体情况具体分析吧 ！

又不矛盾，完全可以多重封装么

这个好处是老板不希望看到的。。。。效率，可用度，银弹，人员成本才是老板喜欢的。

不大懂。
是说既提供大量的封装，同时也留出灵活度吗 ？

可是人总是不停地走，人力资源的成本也不可忽视的。就算封装得再棒，熟悉和使用还是需要时间的。老板不在乎，不代表问题不存在。

你如果会的多了，是否会走的更有理？
用第二种方式公司每年成本的增长是非常快的
而第一种方式下人力成本很低，而增长也慢，
业务量增长快时公司有能力快速转型。。。。

第一种方式常常会被用在外企，
第二种方式常常会被用在创业类的小公司中。

程序员的成长对于一个公司来说不一定是好事。

ＰＳ：大多数老板不傻。。那么大多数老板不在乎的事也必有他不在乎的道理。

本质上，公司最宝贵的财富还是人。

现在更多的公司是找不到合适的人，担心自己公司的开发人员成长太快而导致人力成本过高，听起来实在有些荒唐。也许存在这样的公司和老板，但会不会有点算计过头了？

按照楼上的意思，像thoughtworks这样的公司的人力成本是要增加很快的，但是利润会更快地增长呀。

一个公司的商业模式决定了这个公司会寻找什么样的人才。

对于ThoughtWorks这种以咨询收费方式做项目的公司来说，它的利润远远高于国内的项目公司，同时承担的风险很小。这种运营模式就要求他需要不断寻找高水平的程序员包装成咨询师赚取高额利润。对于招聘的程序员创造的高额利润来说，给程序员多点工资实在不算什么。

但对于国内很多项目公司来说，行业竞争的加剧导致项目的利润非常单薄，同时风险很高，项目周期不确定性拉长，需求随意变更，项目回款困难都导致了公司必须不遗余力的压低公司运营的成本，从而需要招聘大量低工资程序员来完成工作。

前一种情况的问题在于，框架的成熟程度、学习曲线、和框架的维护成本。需要一个核心团队（2－3）个人维护、完善这个框架，培养新人。项目大了，多了，感觉成本降下来了。可是真的有这么通用的框架可以适用这么多项目么？rob 说，检验框架的标准是能够快速实现业务。业务肯定是丰富多样的，所以在这一点上，对通用框架值得怀疑。

后一种情况的问题在于，撞车保险。team走了人，做的这块东西就很可能大改、彻头彻尾的。由于技术的通用性，找两个替换的人还是容易的，可就是以前设计的东西很难继承下来。

前一种情况同样面临如何维持核心团队的问题，而且核心团队出现问题，比后一种更难解决。

max((收入-成本)/成本)
实际上还应该考虑风险耐受力在里面。