跨模块设计时需要重点考虑的技术点

跨模块设计时需要重点考虑的技术点

阅读引导：

1、成熟的组织内部，往往有很多部门，每个部门有很多模块，在数据治理并不规范的情况下，多模块沟通协调需要考虑的技术点较多

2、架构是妥协出来的，这句话带有贬义，但是很多时候在其它因素的约束下的最优解。

稍大一些的组织体系内，组织机构划分明确、领域划分明确。

做一个项目的时候，很多时候需要串联很多的系统模块。

而除非公司内部的规范、数据治理做的非常好（几乎不可能），在跨模块设计方案时，需要考虑一些重要的技术点。

这些技术点，有可能因为是“祖传”，导致前模块负责人分析方案的时候都没有考虑到，会导致后面的进度突然受阻。

1

数据字典

首先第一个需要考虑的事情，由于历史规范原因，各个模块使用的数据字典不一致的问题。

例如：省市的数据字典，资金单位，例如人民币有多种写法：RMB、CNY、001

如果各个系统使用的不一致，会导致大家的数据字典展示问题。

需要提前沟通好。

除了刚才的通用实例之外，设计人员在进行设计时，需要查看相关模块的接口，尤其注意数据字典。

2

报文协议

这一块分为两部分：

通讯协议

HTTP or HTTPS？

或者使用的dubbo的RPC协议？

协议的不同，涉及到一方的改造适配，需要开发工作量。

坦白说，没有一个模块想要适配别的模块的协议，需要涉及人员在早期就提前告知，权衡到底那那个模块做处理。

这样，可以政委精确的估算工作量。

报文协议

对于报文来说，可以有XML\JSON\WEBSERVICE\定长字符串等多种类型。

但是虽然报文协议可以确定，每一种报文协议的具体实现又是不一样的。

例如，xml中的报文头字段长什么样子，业务报文字段结构等。

同理，JSON、webservice都有同样的问题。

定长字符串比较少见，在之前SOCKET方式的接入时有相关的内容。

3

吞吐量

做架构设计的一个重要的点，就是厘清一些自己默认的潜规则。

例如，很多时候大家都默认系统的吞吐量都是可以支撑相关业务的。

实际上，有很多的限制。

举例来说。

一些涉及到外部第三方的功能可能有限制。

例如，人行的系统，提供的类似实名认证的能力，TPS可能仅仅是个位数，那么在进行系统开发设计的时候，就需要考虑队列任务。

而一些工商数据等，同步需要时间，可能与真实的业务场景实际发生，有2-3天或者更多的延迟，会造成数据的不准确。

所有的这些点，不能理所当然的认为所有的系统都是提供最完善的服务。

设计人员必须从一开始就了解这些约束，才能真正设计出满足要求，符合实际工作量的系统。

对于开发人员也有好处，不用设计很简单，实施很困难。

实际上，考虑的约束要素是否全面，也是衡量一个设计师的重要指标。

4

优先级

这一块就是非技术内容了。

在划分了领域组织之后，非常尴尬的一件事情，就是形不成合力。

也就是说，你的项目在别的配合模块哪里，并不是最高优先级。

这就需要你去考虑时间、资源约束因素，提前去沟通、协调。