业务对象层和数据层

spring mvc中  一切皆对象，包括用于表达数据库模型的DTO也是对象。但由于DDD兴起我们发现充血模型在替代贫血模型，原来简单描述数结构的对象现在添加了较多的除了get/set之外的函数。于是，我们需要重新思考一下对象和数据结构的区别。

代码整洁之道中举了一个例子去说明两者微妙的区别
```
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
```
调用者不断获取返回的对象并调用对象的函数，违反了得墨忒耳定律：一个模块只干一件事调用者清楚了太多的细节，而这是明显的数据结构的特征：暴露内在的数据结构。而对象则倾向与只暴露必要的数据域，其余默认为私有域。 但这是由于一些框架和约束要求我们将简单的数据结构也要用到一堆get/set进行传参。

那么正确的做法是什么呢？如果我们要暴露数据结构，最好的方式是 final String outputdir  = ctxt.options.scratchDir.absolutePath;
如果是对象，则应当抽取出合适的函数 比如ctx.getAbsolutPath();

由此我们得到了一个结论数据结构和对象的确是有所不同。
这也是我们原先去区分service层和mapper层的原因。由mapper将数据结构的细节隐藏，提供一个对象提供给业务对象使用。
CURD项目很多时候考虑的就是从数据结构出发，完成数据的CURD,从而将各处的业务逻辑散落一地。我见过controller层中写业务逻辑的，说这是控制层的职责，也见过为了对外（用户）接口和对内（程序调用）的接口完全封装在两个service之间交叉调用的。这可能也是从数据结构着眼导致业务概念上的混乱。

而到了微服务环境，这种情况则变动尖锐和明显了起来。微服务只希望提供服务能力，将外界微服务是为一个能力提供者，而从数据结构层着眼设计的服务就显得不尽如人意。同时，微服务环境下能力提供者的变动速度可能是原来的数十倍。毕竟表结构是件大事，而因为种种原因外边能力提供者变化还是一件挺经常的事。微服务提出了防腐层的概念，但本质上也是将外部的数据结构转成了自己需要的对象，**只要对象函数没变，数据结构的变化是可以被隐藏的**。

将所有架构都抽象成业务服务层和数据结构层之后，我们的架构就清晰了很多。控制层控制是否调用业务，提供业务层必要的参数。业务层操作数据结构完成业务逻辑。而数据层隐藏具体的细节，将数据库、外部微服务等能力提供者统一转成可控的对象。架构变动万变不离其中。

充血模型是抽象的对象在开发时带来了简便，贫血模型为数据结构变动留下了较大的余地。我个人更推荐在数据转换层将贫血模式去加血，否则继承一个充血的业务对象，大概率是会让业务逻辑变得紧耦合或者冗余混乱。这就是repository层。该层以下是数据库或者内存数据结构都可，该层以上则提供充血模型