2014年四月份业务培训的一些思考

关于参加公司业务知识培训以及通过对城市仓系统的性能跟踪（特别是，入库，分货两类核心核心业务的梳理）几点问题的思考

 

一、业务调研阶段思考

我们除了业务知识的理解以及对系统功能的细分之外，发现一些人员提出的问题中对业务领域的不同说法以及大多数分析人员在询问系统的边界在哪？

当然，这是一个不断随着理解深入的分化过程。要回答上述问题，我们是不是应该理一理，业务调研阶段，我们的重点关注有哪些，应该随着什么主线索。

不管来自是软件工程类的教科书还是来自工作中的经验，容易得出结论：

a、业务用例（有哪些用户，有哪些业务角色，有哪些业务场景）

b、统一的领域语言（为各干系相关人交流沟通提供通用的语言词汇）

c、界面原型（功能呈现）

我们现在正在做的更多的是对系统功能的理解，我们的优势也在于已经有浪莎系统这样一个使用体验，已经有个界面的参考。

而浪莎系统作为一个通用型的系统。里面很多冗余功能或是不良的体验都应该是我们所避免的。

通过业务用例，更能了解我们所做的系统是为哪类人使用，这类人更关注的业务场景有哪些。

通过领域语言，可使业务人员，测试人员，开发人员等统一认识我们的业务，一方面更大程度减低人员沟通成本，一方面加快新员工对业务系统的理解。

通过界面原型，使其了解我们未来的系统是一个什么样子。前期得到更多的业务人员的反馈意见，继而调整我们的设计方案，一步一步细化我们的系统功能。

这样实施下去，最终我们得到的将是一个更符合我们公司业务场景的系统。

 

业务调研最终需要产生业务务需求规格说明，里面重点罗列上述三类（业务用例，领域语言、界面原型）内容。进而为后续的系统需求分析设计，架构设计等提供指导。

 

二、现有系统设计的思考

对城市仓系统（WMS-CITY）两个核心业务的了解，以及对业务管理系统和常规互联网应用系统对比，有几个问题需要我更深入思考。

通过之前的零售分销系统的总体介绍与对未来系统的建设要求，以及目前我们所使用的浪莎系统现状的分析。对一个CS架构的信息系统改造一个基于BS架构的信息系统，改造过程中 我们会遇到哪些重大技术问题。

在思考这些问题之前，大致先想了对管理系统的认识以及在CS架构系统下，分析设计问题的角度，对业务建模的不同。

在CS系统架构下，大部分开发人员首先依据数据为中心的建模，上来就是数据库表的设计，紧接着就是业务实现存储过程化。这是一个很自然的结果。

这里，我们不去区分CS、BS架构的区别。而要想一个问题是，给我们的开发人员长期的这种分析设计影响导致我们再转型BS架构的设计上造成了哪几类重要问题。

a、设计僵化

b、可扩展性差

c、伸缩性弱

d、易性能瓶颈

对于这些问题的讨论，也很容易陷入对编程语言的比对，面向过程对面向对象，以及一些开发设计模式的讨论中去。暂时抛开这些因素。聚焦在城市仓系统中的两类核心业务上，入库与分货。

对入库在业务流程上有个定位业务的处理，根据定位策略寻找储位，以及分货业务中，要根据分货策略，规则产生分货单。这些都是计算密集型的任务处理，使用存储过程实现。本应善于 处理业务逻辑的应用层却成了很弱的一层，只是一个过程调用。在请求量大对服务器造成的压力全部集中在了数据库服务器上。当然，我们可以考虑分库，分表等技术手段解决。可在成本上， 技术实施难易程度上，对整体系统的影响上考虑这些问题，会选择在应用层上做伸缩。

  想着上面的问题很自然让想到 在对我们平台架构系统建设中，要将产生一些设计僵化，易产生性能低下，影响系统伸缩，以及成本上会大幅增加等这些问题扼杀在摇篮中。

在编码设计之前协助开发人员分析设计，给出方案来规避这类问题。要求我们各个项目组的设计要通过专家组评审，代码实现定期CodeReview等这些很具体的事项。

 

三、零售分销系统的设计思考

重点补充一下两点

a、架构设计上：在公司现有的架构设计原则指导下，最大程度引入异步处理。（ 分系统内并发处理，系统间并行处理。）

b、业务功能实现上：尽可能自动处理替代人工处理。

分析调研人员根据调研结果，凡是可以自动完成的业务功能，注意引导业务人员是否可以系统自动完成。减少业务人员对系统的操作， 将关注点更集中在线下业务实施操作上。