作为一个码农终于把MySQL日记看懂了,【Spring Cloud 2

接下来,还有什么不同原因的变更呢?答案正是这些业务逻辑本身!在每一层内部,不同的业务场景发生变化的原因、频次也都不同,不同的场景我们分别定义为业务用例。由此,我们可以总结出一个模式:在将系统水平切分成多个分层的同时,按用例将其切分成多个垂直切片。这样做的好处就是对单个用例的修改并不会影响其他用例。

如果我们同时对支持这些用例的UI和数据库也进行了分组,那么每个用例使用各自的UI表现与数据库,这样就做到了自上而下的解耦。另一方面,有层次就有依赖。在OSI协议中,上层透明的依赖下层。但是在软件架构中,我们更强调“依赖抽象”。即组件A依赖B的功能,我们的做法是在A中定义其需要用到的接口,由B去实现对应接口能力,这样就做到了可插拔,将来我们可以把B替换为同样实现了接口能力的组件C而对系统不会造成影响。

二、整洁架构


分层架构中给人的感觉是每一层都同样重要,但如果我们把关注的重点放在领域层,同时把依赖关系按照业务由重到轻形成一个以领域层为中心的环,即演变为一种整洁的架构风格。这里不是说其他层不重要,仅仅是为了凸显承载了业务核心的领域能力。

整洁架构最主要原则是依赖原则,它定义了各层的依赖关系,越往里,依赖越低,代码级别越高。外圆代码依赖只能指向内圆,内圆不知道外圆的任何事情。一般来说,外圆的声明(包括方法、类、变量)不能被内圆引用。同样的,外圆使用的数据格式也不能被内圆使用。

整洁架构各层主要职能如下:

  1. Entities:实现领域内核心业务逻辑,它封装了企业级的业务规则。一个Entity可以使一个带方法的对象,也可以是一个数据结构和方法集合。一般我们建议创建充血模式。

  2. Use Cases:实现与用户操作相关的服务组合与编排,它包含了应用特有的业务规则,封装和实现了系统的所有用例。

  3. Interface Adapters:它把适用于 Use Cases 和 entities 的数据转换为适用于外部服务的格式,或把外部的数据格式转换为适用于 Use Casess 和 entities 的格式。

  4. Frameworks and Drivers:这是实现所有前端业务细节的地方,UI,Tools,Frameworks 等以及数据库等基础设施。

三、六边形架构


我们把整洁架构的外部依赖按照其输入输出功能、资源类型进行整合。将存储、中间件、与其它系统的集成、http调用分别暴露一个端口。则会演变成下面的架构图。

系统能平等地被用户、其它程序、自动化测试或脚本驱动,也可以独立于其最终的运行时设备和数据库进行开发和测试。

最后

现在正是金三银四的春招高潮,前阵子小编一直在搭建自己的网站,并整理了全套的**【一线互联网大厂Java核心面试题库+解析】:包括Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等**…都已全部整理上传在**我的腾讯文档上:点击这里前往传送门**并会持续更新…可以star一下。

点击这里前往传送门**并会持续更新…可以star一下。

image

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值