5年前给我职业生涯带来重大影响力的开发架构、开发思想（软件分层架构、UML的重要性）

大家都讲，做日本外包学不到知识，只是低级的编码工作，我从来不认同这个观念，我做日本外包大概有1年多时间，
这期间也是我提高非常快的一段时间。

说实话，自从接触了日本外包后，我才觉得我自己终于变成软件人才了，脑子里懂点儿东西，有些内容了，知道什么
叫规范，什么叫质量，什么叫规模化生产，什么样的人才是软件人才，当然也见到了管理类软件开发领域的顶尖人物。

那是几年前在上海做日本外包，当时是做NEC公司的外包，我这个人喜欢研究别人的架构，多学习别人的优点，这个
架构里我做开发前后有2个多月，这期间我把这个架构理解掌握了一些。

这个是在2004年时，我参与的一个项目，5-6年的项目了，时间过得也很快啊。

废话少说，先来个架构图：

此UML设计也是我非常佩服的设计之一，也是我梦想中我希望能达到的境界。
简单扼要的介绍一下功能：

1. 页面表示层：首先说明了这个页面上会有几种操作，页面有几种状态，例如：页面加载时、查询时、审核通过时、驳
回时等等。
2. 事务控制层：这个层是负责打开关闭数据库，控制数据库事务的，例如要么一系列操作都成功，要么一系列操作都失
败回滚，
还可检查一个数据库打开于关闭之间，运算花费了多久时间，页面调用这个服务几次，是不是有重复调用现象等。
3. 商业逻辑层：这个层主要负责逻辑运算，商业逻辑代码，没有跟数据库直接打交道，纯商业逻辑控制代码。
4. 实体控制层：这个层说白了，就是数据库层，负责与数据库的存取、更新、删除、统计等功能，数据库的直接交互都
写在这个层里。
5. 数据库表层：应该是物理层吧，就是数据库里应该有哪几个表，哪几个类，会跟这些表有关系。

你可能认为，这有啥的？不是很简单的吗？那你回答我，你的系统架构能达到这个水平吗？页面与数据库完全无关吗？
商业逻辑层与数据库完全无关吗？估计，你不敢给我肯定的答复，真的严格这么分层写，那工作量是相当的大的，还是
乱八七糟的写写，效率是最高，但是不容易沉淀成果物，不容易形成积累，做了多少项目，都是来一个重新搞一个，不
会达到能重复利用的最高境界。

其实这个设计中，最厉害的之处是：
1. 设计人员，在脑子里，已经严格的将此模块进行了推演，这个页面到底需要哪几个状态，哪几个方法，哪几个类，
互相之间什么调用关系，都设计好了。
2. 此系统重视的数据库的打开关闭效率，在一个打开的连接里，做N个事项，并把这些事项，放在一个事务里，进行
事务控制，一个页面上的动作，不会
重复多次打开关闭数据库，若那样，无法放在一个事务里进行控制。
3. 这个系统的，调用线的箭头方向都标明得非常厉害，简直到了佩服的境界，你可以仔细体会体会，我是事后才发现的，
真的太仔细了。
4. 这个系统可以做到多种数据库的支持，稍微做修改就可以支持多种数据库结构，或者干脆数据存放在xml文件等，
或者其他文件里。
5. 这个系统，发布时，可以将 web 服务器与数据库服务器分开来，不是在web页面里打开关闭数据库的。

不足之处：
1. 函数名没有写出来，因为是日文的项目，有时候给一个方法命名，还真闹心，若方法名都写出来了，那开发起来，
真省老多事情了。
2. 函数需要几个参数，其实都可以规定出来，例如接口一样，那写程序的人，不会容易瞎搞了，设计是好，但是写
代码的人很烂啊，他脑子里就想着，做日本外包项目学不到啥，能跳槽就跳槽，天天投简历，找面试机会，根本没
有静下心来自己体会，仔细琢磨。

天外有天，由于我亲身经历了此项目的开发过程，给我的体会很深，让我学到了很多，这个架构若是今天拿出来了，
没多大意义，大家都能好理解了，但是在好多年前，还算是理念很先进的，并且这个项目还有很多很多架构外值得
学习的地方，我想陆续发表几个文章，分享给大家。