业务抽象及分层

因为碰到了关于业务抽象和业务分层的一些问题，确实也发现自己在这方面的逻辑思维稍微薄弱了一些，记录一下抽象和分层的一些思路。

抽象的目的

首先我们做抽象是为了简化事物，对一种概念或者一种现象进行过滤，去除掉我们不需要的信息或者多余的信息，只保留其本质。

当然，因为目的的不同，我们的抽象是需要分层次，拿维基百科上的例子来说：

1. 我的12月1日的《旧金山纪事报》
2. 12月1日的《旧金山纪事报》
3. 《旧金山纪事报》
4. 一份报纸
5. 一个出版品

比如说，我们只想了解这份《旧金山纪事报》的日期和报名，并不想知道是谁的，就会抽象成第2个选项，同理，若我只想知道这件事物是什么，将会层层抽到至最简单最容易理解的层级，一个出版品,，其余的信息对我来说都是无用的。

开发中的抽象

在软件开发中，其实分层就是抽象，不论是底层的操作系统还是往上的编程语言都会涉及到分层抽象。

开发中最经典的mvc模型，核心其实就是抽象的分层，软件开发本身就是不断抽象的过程。我们把业务需求抽象成数据模型、模块、服务和系统，面相对象开发时我们抽象出类和对象，面向过程开发时我们抽象出方法和函数。

抽象的原则

1.单一职责原则（Single Responsibility Principle, SRP）

       单一职责是指一个模块应该只做一件事，并把这件事做好。其实对照应抽象的定义，可以发现这个原则本身就是抽象的核心体现。如果一个类包含了很多方法，或者一个方法特别长，就要引起我们的特别注意了。例如下面这个 Employee 类，既有业务逻