系统服务化-软件设计就是反复咀嚼，反复推敲，螺旋式学习

有没有想过软件设计的思想是如何度量和呈现的，并细化到工程实践中的？本文基于单一职责和关注点分离两个设计原则进行延伸和应用复盘。

阅读了两篇技术文章，综合起来记录一些重点。来源于极客时间《程序员练级攻略：软件设计》和 《软件设计之美》

单一职责

单一职责指每一个类只负责自己的事情。

职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大地损伤其内聚性和耦合度。

单一职责，通常意味着单一的功能，因此不要为一个模块实现过多的功能点，以保证实体只有一个引起它变化的原因。

一个类，只做一件事

关于单一职责原则，其核心的思想是：一个类，只做一件事，并把这件事做好，其只有一个引起它变化的原因。

单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因

分离关注点

将问题分解为较小的独立的问题
实现关注点分离的方法有两种，一种是标准化，一种是抽象和包装。

延伸

我在做软件项目搭建时，有几个原则不会动。屡试不爽。
第一 会拆分出基础应用层和上层应用层。
第二 应用层内部至少分三层，对外暴露层，业务服务层和数据化持久层。

按原则和项目标准搭建的项目结构是后续执行单一原则和关注点分离的基础。

以上两个原则对于关注点的分离的粒度上远远不够。

应用

之前设计过一个系统，基础数据来源于第三方服务，服务进入自身系统后，按照状态进行自身系统内部的数据流转。

这种方式就是基于外部数据做业务，从外部数据转化为内部系统数据，有几个关注点

第一 外部数据源的获取方式是哪种，推方式还是拉方式？

第二 通信层数据传输是否稳定，是否需要幂等处理

第三 数据延迟或者获取堆积后，对自身系统有何影响？

比较直接的做法是第三方服务数据通过拉取或者推送方式直接进入自身业务系统数据库，然后用状态标记各个阶段的数据处理。

这样做的隐患

数据源和业务数据没有实现分离

数据获取积压或者延迟时，源数据的处理会影响自身业务系统

按照分层和关注点分离后，如下图所示，将数据传输和业务处理按层次分开。源数据不直接进入业务系统数据库，可以引入消息队列，做数据隔离

关注点分离-分层

可以通过以下几个点寻找需要分离的关注点

技术和业务的分离，程序最终是要解决问题的，不能把所有的问题都归结为技术问题。

数据变动的分离，如上文中通信层和数据层的分离,动静分离，读写分离等

高频和低频的分离，是否是常用的操作对于技术选型会起到决定作用。

发现软件设计和架构之美

摘录技术文中的几句话作为结尾

架构之路越走越无知，一如人生路。

尊重架构师的力量，一如尊重未来的你。

高明的架构师心里藏有无数的架构设计方案，但对于不同的场景，他会选择最合适的那个来实现

架构更像一种艺术而不是科学，反复咀嚼，反复推敲，螺旋式学习。