首先，想问读者朋友，你有没有在Service层的一个业务方法里，写过一千行以上的代码？小编干过这事。前半段不亦乐乎，后半段枯燥乏味。这是为什么呢？其实，回看我们的代码，你会发现，我们只是用了一个面向对象的语言，在写一个面向过程的程序。
为什么这么说？举个例子，就拿电商的下单业务来说。客户下单，需要创建一个订单，并且减少相应的库存（这里只是举例，不做具体的业务细究）。
数据模型
这里就引出了数据模型的概念。我们需要首先要创建Order订单对象，Stock库存对象，用来映射数据库。这两个对象就被称为数据模型。这两个对象的代码，除了属性就剩下Get和Set方法了，如果引用了lombok，连方法都不用写。
为了操作数据库，我们还要创建OrderDao对象，StockDao对象。这两个对象主要是调用数据库驱动api，完成数据的增删改查，如果引用了持久层框架，多数情况下，这个类里面什么都不用写。
为了保证事务，我们还会在业务方法上，加上事务注解。业务代码就是调用OrderDao创建一个订单，再调用StockDao减少一些库存。
一切看起来是那么的美好。全程都是对象，我们感觉我们是在面向对象编程。
其实整个过程就是一个实实在在的面向过程的编程。我们只是用Java语言翻译了一下MySql存储过程而已。
业务模型
在Java世界里，有一句经典名言：“万事万物皆对象”。那么下单这个业务，也应该是一个对象才对。
我们应该再创建一个OrderLogic订单业务对象，这个对象有创建订单，取消订单，支付订单等行为业务。Service层的业务方法，应该调用订单业务对象的创建订单业务，来完成订单的创建。
读者会觉得，这好像与之前没啥差别，只是把Service方法里的代码挪了位置，还无端的多了一个对象，多了一次调用。
其实，面向对象本身就是一个思想，而非一个标准。有了业务模型对象之后，编写业务模型代码的程序员可以只