SOA四层架构中的服务层设计

2019独角兽企业重金招聘Python工程师标准>>>

最近在做的项目，电商平台中的商品服务，属于电商平台中最基础的服务。项目整体架构——SOA服务治理的方式。这个项目属于重构项目，由php重构为java。自己在项目中的角色coder+架构吧。

项目的层次结构四层，export(对外暴露的dubbo接口)、facade(业务归集)、service(具体业务)、dao(数据持久)。按道理说的很清楚，但是每个人都对这四层架构有各自的理解，实现就不太理想了。

开始大家各写各的接口，每个接口都有自己的sql，自己的service，各种model实体类，facade只是一个空壳，代码完全不复用。老实说当时写的很痛苦，我希望的结果是dao层和service层是基础接口，能够复用，划分好领域对象，每一层只操作自己的领域对象。跟同事争论了很久，也跟项目经理讨论过。为了赶进度，大家都没有在意。最后项目经理看了下代码，发现写的非常烂，又在一起讨论了下。最终决定service和dao按我说的方式重新开发，然后让我一个人开发。

因为以前做的项目都是小项目，而正在做的项目又属于业务复杂，数据量巨大的项目。写代码的时候还是遇到了很多问题、项目也接近尾声。就把做项目时的一些想法简单的罗列下。

1、定义service接口时，最重要也是最先做的是定义service实体。通过service实体要能体现出业务对象之间的关系，该实体为项目所属领域的实体，如果系统业务复杂，定义该实体一定要和同事和leader讨论下。

2、虽然理论上service层的model和表应该没有对应关系。但是为了避免过多的对象转换，我觉得service实体可以体现出表与表关系。mybatis可以直接映射到该实体。这种实体我之前的项目会加DO后缀，可以理解为Domain Object，也可以理解为 Dao Object，它包括数据表的所有字段和一些业务字段，作用域只限于Service和Dao。

3、service层提供的方法首先要简单，属于原子性的方法或者服务，能够充分复用。然后是这一层只做本领域的业务，保证事物的强一致性，做到高内聚、低耦合。

4、facade层做业务归集，它负责与其他系统做交互，还有数据转换。数据转换也是一个很纠结的地方，如果你要写在分层的代码中，将有大量的get()、set()方法，当然你也可以使用BeanCopy(),前提是你定义的属性名要DO一致。使用BeanCopy，有个很大的缺点，这样会不知道出参是在哪里赋值的，排查问题就有点困难了。

5、特别说明一下，我们的系统入参层次对象应该是由VO到DO，或者DTO 到DO。出去就是由DO到DTO，或者DO到VO。在我之前的项目中，会在DO中定义多个静态方法，用作将DTO或VO转为DO，DO转为DTO或VO。这样这个DO就是一个充血的bean，但是如果业务复杂实体比较多的话，DO就会有太多这样的方法。这就需要自己去权衡了。

6、对于增删查，可以把service方法写的很通用，利用mybatis的动态sql可以有很好的扩展。但是对于修改，如果所有修改的操作都是一个update方法的话，容易出现传递不同的条件而发生不想要的修改的情况。所以会有多个修改方法。这样同样会带来其他问题，后面说到缓存设计再详细说。

7、分包和建类要按DO来。做这个项目最大的两个坑，一个就是各自写各自的代码，完全没有服务化的思想，这个后来改过来了。另外一个就是分包了，这个坑还在，已经是积重难返了。我们现在分包和建service类是按功能分的，比如所有的查询放在Query类中，所有的编辑放在manager类中，这就造成本来该属于一个DO的业务割裂在不同的类中。

8、前面说了Dao操作的对象是DO，但是对于查询来说，我们又不会完全按照DO的属性去做查询，我们希望可以通过一个类知道这个DO的查询条件来筛选数据，这就需要根据每个表来建一个Query类，这个类原则上不应该有id、idList类似含义重复的属性，但是可以提供一个setId()方法。

9、当一个表有很多字段时，比如我们的商品表有100多个字段。我们每次查询不应该带出来所有字段，这就需要对字段进行分级，根据不同级别提供多个查询方法。因为还存在表关联的情况，还要提供是否级联子表的参数，这样一组合查询的方法就多了，所以设计查询的时候，也要想清楚。

转载于:https://my.oschina.net/everyDay111/blog/732518