认识达内从这里开始

我们在前几期的文章中给大家简单介绍了程序员需要掌握的一些架构方法等内容，而本文我们就再来学习一下，软件架构实施需要做什么。

1：明确系统该做什么，而不做什么

这个非常重要，清晰的边界，有助于整个系统的架构设计和开发实现，能更好地帮助我们达成软件建设的目标。

比如我们的系统，只需要做到下完订单过后生成出货单，后续的业务就不需要我们的系统来处理了，可能就是推送出货单到ERP或WMS(仓储管理系统)等三方系统就可以了。

那我们就不能瞎做，把出货单后面的业务也做了，美其名曰业务闭环，胡做一通，该做的没做好，不该做的做了一大堆，浪费人力、物力、财力和时间。

这就是说，我们必须明确的知道，系统该做什么，而不做什么。

2：明确系统与周边系统的关系

系统与周边系统的关系，指的就是我们的系统和相关的三方系统，相互调用、交互的关系。

比如上面提到的例子，我们的系统负责生成出货单，然后推送ERP，那么ERP就要有相应的接口，并且给出数据结构的要求，也就是说我们生成的出货单，里面需要哪些数据，要组织成什么形式，都是由ERP来决定的。

同样，调用ERP接口过后，我们需要获取返回的结果，一种是同步等待，另一种是异步获取，那我们就需要提供异步回调的接口，并规定好需要返回哪些数据，以及数据的组织形式，这个是由我们系统来决定的。

我们的系统并不是孤立的，可能只是大业务场景中的一个环节，必然要和其它相关系统进行交互，否则很多业务也就无法完成了。

所以，我们系统和所有协作完成业务的三方系统，之间的这种交互关系，是一定要明确出来的。

3：明确系统在整个大业务场景下的定位

这个就是要理解，在用户整个业务场景中，我们的系统，承载的是那一部分。

客户的业务，可能有生产的、设计的、制造的、销售的、客服的、物流的、财务的等等大业务场景。

我们做的系统，假设是电商系统，那么实际上做的就是销售这个大业务场景里面的一部分，那么这里面就不会涉及什么生产、设计、制造等业务。

就算在销售这个大业务场景，可能我们做的也只是其中的一部分，比如客户的销售又分成线上销售和线下销售，线上又有toB的、toC的、B2B平台销售等等的，而我们可能只是做了其中toB的部分。

大家可以看到，明确系统到底在哪个大业务场景下，具体承载哪部分功能，对于我们理解系统的业务，明确系统的边界，都是非常有帮助的。

4：明确系统的运行环境以及前置条件

我们需要知道，未来我们的系统运行在什么环境下，比如：部署环境、服务器多少、软硬件情况、网络带宽的多少、其它配备的资源的多少等。

这直接影响到我们架构设计的选型，还有对质量约束中的一些关键元素的达成，比如性能、稳定性等等。

另外，我们还需要知道，要让我们的系统正常运行起来，需要哪些系统，因为我们的系统只是整个大业务场景中的一部分，需要从三方系统去获取一些数据，也需要把一些数据传递给三方系统，否则业务是无法完成的。

因此，我们需要明确系统的运行环境以及前置条件。

5：明确系统与相关系统的交互：

(1)交互方式

是同步调用还是异步调用，是我们去调用相关系统，还是相关系统调回来。

同步方式是采用数据库同步，或者是采取异步消息同步，还是采用OpenAPI的形式等。

这些交互的方式都要明确下来。

(2)交互频次

多长时间交互一次，有些可能是实时交互，有些可能是定时交互，比如一天交互一次等，这些都要明确下来。

(3)交互数据量

每次交互，大概会有多大的数据量，大数据量可能是多少，需要进行压缩、加解密等处理吗，这些也是要明确的，这对架构设计是有影响的。

(4)交互限制和约束

跟其它系统交互，有没有什么限制，比如一分钟多交互次数，大传输的数据量，每次交互处理长的时间等，这些也是会影响到架构设计的，都需要确定下来。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音达内三江区域学习了解。