这不是什么新鲜话题，但是最近在维护一个之前同事遗留下来的项目，有了一些感想。其实我很久都不做具体的业务了。很长一段的时间主要在负责基础设施以及业务工具方面的开发，所以我做的事情，往往并不需要和具体的业务打交道，其实这样挺困难的，关键在于我并非设计者，设计者是其他的专职设计师，他学历高，工作时间也长，但是可惜的是，他在web系统的架构以及设计上并没有多少的经验，所以其实事情也挺难做的。
而现在接手的这个项目是一个很纯粹的业务系统，没有太多的自主设计，用的是标准javaEE的那一套，从技术上面来说是无可厚非的。但比较糟糕的是整个系统没有对业务进行建模，而是把业务分布在众多的RESTful API以及SQL语句上了。我觉得这其实是一种维护的灾难，太多的API把业务分割的支离破碎，根本不知道这些API什么用。系统的目录结构是按照技术来划分的，这种划分方法我必须吐槽一下，业务被隐藏在毫无意义的技术名词下面了，大大增加了人的理解难度。
所以我觉得应该对业务建模，至少在程序中能看到业务的脉络，而并非是一堆技术名词。而且这样也比较容易让人意识到各个业务模块之间的界限，不会把所谓的DAO什么的service什么的搞得过于的臃肿。之所以容易选择用技术名词来命名系统中的文件夹，我觉得主要是因为根据业务命名是比较困难的，这是因为：
- 业务总在发展和变化
- 业务没有明显的界限
- 业务之间总是相互牵连
- 无论业务多么的复杂，实现的技术总是不变的
似乎我们按照技术来组织我们的代码，也没有什么不对的。
所以组织代码有两种情况：
- 技术-》业务
- 业务-》技术
第一种方式最常见，使用spring的人一般都是这种风格。你会发现其代码结构中，顶级的文件夹命名都是技术名词，什么DAO，什么service之类的。一个业务相关的代码往往分散在这些文件夹里面的各个类中。这样的做的后果就是，永远不知道业务在哪里，看不见，摸不着。随着业务的变化这些文件夹中的内容都在变化不止，最终也无法抽象出一个模型以便重用。代码的复用性为：零。
这种代码里面随处可见大量注释掉的代码，以及各种补救措施。代码膨胀的速度惊人，一个巨大无比的焦油坑已经出现在不远的地方了。吐槽一下：在很久之前，我们学习UML的设计方法的时候，一定需要对业务建模的，后来有了EJB，这个也需要对业务建模。后来有了WEB系统的流行，以及Spring的出现。但不知道是哪个天才开始程序里面再也看不见业务模型了。业务是不可能消失的，不建模的一个重要原因是，这些业务可能十分的简单，但是它不可能永远都是简单的。特别是如果你希望积累或者希望复用的话。以技术为核心的这些项目被复用是十分困难的，因为你需要精心的拆解它们，和重做其实差不多了。
第二种方式，我觉得比较好。它有一个很重要的优点，就是可以复用。并且，从某种程度上来说，抽象的业务并不依赖具体的技术实现，这样对于业务的优化很有好处。此外，对于大多数的公司来说，业务才是真正有价值的东西，技术不是核心，技术仅仅是价值的载体，价值体现在业务里面。但是它有一个最大的缺点，就是难。对实现者要求很高，搞出一个很好的模型比较困难。就是这样。不是能够通过读书，读学位就能达到的，需要大量的实践，以及比较高的天赋。