SOA系统架构的体现之springboot+mybatis框架
题外话 ：为什么要选用SOA架构
不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。
下面进入主题：
本例是springboot+mybatis+gradle构建而成
如下图是工程的目录结构：
构建工程和其它springboot的工程构建流程一样，这里主要记录一下几个在实际工作过程中需要注意的地方。
工程属性的配置文件环境化
顾名思义，一个正真的工程都是要进行不断的环境变化的，这就要求工程必须在很小的改动情况下适应不同的工作环境，简单点比如在开发环境，测试环境以及生产环境，这是比较通俗的环境定义，当然在不同的企业要求下可能有些不同。但不管怎么样，对于工程而言要都有高度适应性。springboot提供给我门极简化的工程配置application.properties,里面基本可以满足简单工程的所有配置。这是对于工程而言的，对于环境而言，springboot并没有从这层面来解决我们的问题，需要借助第三方工程管理工具来帮我们解决这个问题，比如maven，比如gradle,下面我们列举在gradle中是如何操作的。
-1) 引入environment概念，操作而言，既在主目录下创建environment，并在里面定义环境目录，如图：
- 引入environment后需要我们的构建工具gradle进行配置，使得gradle构建工具去识别认识它，所以我们在build.gradle中添加可扩展变量ext.env = hasProperty(“env”) ? env : “dev”，如图：
至此，配置文件在可变环境下的配置就OK了，可以使用命令 gradle build war来感受一下打出来的包是否是相同的路径下了。
-2) 记得在操作上面的步骤之前把本地包引入，不然之前的一切都白搭了，如图：
最后打包完的结果是：
工程的日志输出合理化
springboot的配置文件可以帮我们解决日志配置的问题，但是如果不加热部署条件，日志格式就显得有点鸡肋，于是我们可以自定义日志格式，即在主目录下引入logback.xml配置文件，spring boot会自动扫描该文件并加载相关bean,如上图目录。日志文件也可以做到在不同的环境中有不同的配置，这个和上面的步骤一样。
工程目录结构的层次化
工程目录的层次化是必须要做的事，没有清晰明了的层次结构，工程到最后会很乱，对代码的管理是极为不便的，甚至会影响到构造部署包时对相关目录操作的复杂化。所以我们要做到： 先层次化–>模块化–>结构化, 以此保证代码的管理的健壮性。
在最后要强调一点，如果工程使用的是mybatis，切勿将sql脚本与Java代码以及Java文件目录糅合到一起，这样严重违背mybatis的初衷：高度可配置，高度可维护。
题外话，有一位前辈Java程序员一天问我，gradle熟吗？我说会用。他说：“你懂它的原理吗？”“这个真不懂”。对于我们大多数程序猿来说，它就是个工具，你无须去深究他的原理,能够熟练运用它即可。工程使用maven或者gradle构建都一样，初学者无须纠结该使用什么工具，哪个熟悉就用那个。等能够深刻理解工程构建思路时，可以尝试相互转化，融会贯通。
比如maven工程和gradle的相互转化，就很简单，你想知道吗？关注我，私信我都可以。我会在后面专门写一篇文章来讲述。
