这几天在做一个项目的维护，一个业务模块要增加几个字段。本以为没有什么工作量，可随着事情的进展，事情变得不那么简单了。
这个业务模块需求是这样的，该业务模块是系统的关键模块，一共有三类用户能操作该业务数据，三类用户的操作页面基本上类似，只是个别字段不一样、后台业务逻辑基本上一致。开发时做法是，做完A用户的界面及业务逻辑，然后复制二份，然后在这基础之上稍微改了一下，另外两类用户的开发工作也就完事了。开发时是省事了，但后期的维护可就变成恶梦了。现在的情况是要修改，需修改三个地方。
为什么会出现这种情况？我想是我们的设计人员还没有意识到业务架构的概念，只徒设计时简单，至少也得抽出一个公共模块来吧。正好前段时间看了《Thinking in UML》这本书，书中也谈到了业务架构的问题，感觉作者的思想境界还是十分高的。呵呵。下面摘取本书上的一些观点。
在项目开发过程中，当我们获得一份需求时，如果不建立业务架构，这份需求对我们来说是一盘沙子，每次我们都要从头把沙子做成砖块，一点点辛苦地开发程序。而建立业务架构的工作，就是要把沙子变成各式各样的零件、部件，从零件做起而不是从沙子做起，像拼图一样，拼出我们的世界。
业务架构，实际上就是在对需求细致分析和深刻理解的基础上，抽象出若干相对独立的业务模块，形成自洽的业务构件。这些业务构件对内可以完成一个或一组特定的业务功能，对外则有着完善接口，可以与其它业务构件共同组成更为复杂的业务功能，直至构成整个系统的完整业务功能。
至于如何获取业务架构大家有兴趣看看书吧。在书中作者还谈到了划分子系统问题，下面是一些观点。
业务子系统与计算机子系统是两回事。计算机子系统描述了一个软件的内部构成，它的划分依据是对象依赖，目标是构件扩展性好的软件结构；而业务子系统描述的是软件展现形式，它只是表现成这个样子。换句话说，用户看到的业务子系统只不过是由界面名称、菜单名称等信息表现出来的，并不代表软件内部就一定与之相符。
下面是业务子系统与计算机子系统之间的关系：
欢迎大家讨论。