可以怎样设计欣农互联的业务系统

这里我主要想强调下中间代理中间状态的重要性。业务系统发起一笔业务,中间系统接收业务系统请求,封装通信协议 发送给银行,然后银行解析请求,操作具体业务,将结果返回给中间代理,中间代理负责解析请求,将结果告诉业务系统。试想中间代理要是状态不明,哪条链路断了都不清晰,解决问题就十分困难了。

其中涉及到4个链路,每个链路都有可能出问题。而且中间代理层要涉及到对请求和响应消息的编码和解码,有可能会因为一方的更改没有告诉另一方导致失败,所以中间代理层必须得定义出6个状态来标识一个正常的请求响应链路进行到了哪一步,而且都要详细记录请求报文和响应报文。

只有把这些状态边界定义清楚了,才能知道系统的问题出在哪里,才会有针对性的解决方案。

其实不仅仅是业务系统,设计到很多层面。例如 当我们的业务系统依赖MQ来做解耦时,就可以利用中间状态来实现消息的一致性问题,要保证业务成功 消息就成功，同理,业务失败,消息也要失败。(具体可以参加大型网站与java中间件中的互联网中间件这一章节)

系统设计的主要任务是在系统分析的基础上，按照逻辑模型的要求，科学合理地进行系统的总体设计和具体的物理设计，为下一阶段系统提供实施提供必要的技术资料。

系统设计是新系统的物理设计阶段。根据系统分析阶段所确定的新系统的逻辑模型、功能要求，在用户提供的环境条件下，设计出一个能在计算机网络环境上实施的方案，即建立新系统的物理模型。

扩展资料：

系统设计的原则：

1、易用性原则

方便上网客户浏览和操作，最大限度地减轻后台管理人员的负担，做到部分业务的自动化处理。

2、业务完整性原则

对于业务进行中的特殊情况能够做出及时、正确的响应，保证业务数据的完整性。

3、业务规范化原则

在系统设计的同时，也为将来的业务流程制定了较为完善的规范，具有较强的实际操作性。

4、可扩展性原则

系统设计要考虑到业务未来发展的需要，要尽可能设计得简明，各个功能模块间的耦合度小，便于系统的扩展。如果存在旧有的数据库系统，则需要充分考虑兼容性。

参考资料来源：百度百科—系统设计

系统设计应考虑的有以下主要问题：

进行系统设计时，必须把所要设计的对象系统和围绕该对象系统的环境共同考虑，前者称为内部系统，后者称为外部系统，它们之间存在着相互支持和相互制约的关系，内部系统和外部系统结合起来称作总体系统。

因此，在系统设计时必须采用内部设计与外部设计相结合的思考原则，从总体系统的功能、输入、输出、环境、程序、人的因素、物的媒介各方面综合考虑，设计出整体最优的系统。

扩展资料：

系统设计通常应用两种方法：

一是归纳法。

归纳法进行系统设计的程序是：首先尽可能地收集现有的和过去的同类系统的系统设计资料；在对这些系统的设计、制造和运行状况进行分析研究的基础上,根据所设计的系统的功能要求进行多次选择,然后对少数几个同类系统作出相应修正，最后得出一个理想的系统。

二是演绎法。这是一种公理化方法，即先从普遍的规则和原理出发，根据设计人员的知识和经验，从具有一定功能的元素集合中选择能符合系统功能要求的多种元素，然后将这些元素按照一定形式进行组合（见系统结构），从而创造出具有所需功能的新系统。

参考资料：百度百科——系统设计

系统分析与设计的基本原则

一、统一性原则。按照国家税务总局的出口退税的法规政策，兼顾各地业务处理的特殊性，制定统一的出口退税业务规范。

二、适用性原则。系统提供灵活的设置，保证各地在不违反基本退税流程规范的前提下，适应其手段和操作方法的不同。另外，本系统应是一个不断提高完善的系统，系统要能够进行不断的发展，同时能最大限度地适应未来的业务发展的需要。

三、易用性原则。本系统使用人员范围广，使用人员的计算机水平层次不一，有的基层单位计算机使用水平较低，很多地方缺少计算机专业人员，系统应尽可能的操作简便，维护简单。

四、可靠性原则。由于操作失误出现的故障，重新使用时，系统应有自举功能，一时的设备故障，系统应可进行恢复，不破坏数据的一致性和完整性。

五、安全性原则。系统的用户根据业务的需要，具有不同的安全级别及操作权限，系统要充分发挥操作系统、数据库、应用软件三层安全保证措施，以保证数据的安全性。系统内部重要业务操作均留有痕迹。

六、健壮性原则。本系统接受大量的外部数据，系统应对错误的数据和结构不合理的数据进行识别，拒绝接受错误数据和结构不合理数据。

七、易二次开发、易维护性原则。采用封装技巧，建立稳定的底层工具，核心技术文档随系统发布等手段，使具有基本技术水平的系统维护人员可以在一定程度上对系统进行较复杂的维护及一般性扩充。

大家都知道如果能把缺陷扼杀在编码之前可以节约很多成本，缺陷发现越晚花费的成本越高，尤其是设计上的缺陷如果到了编码后期甚至即将上线才发现也许会导致整个项目失败。所以现在越来越重视需求评审和设计评审，在前期投入的时间也会越来越多，但是有时候往往没有想象的那么好，投入的时间和收获不成正比例。那么在需求评审和UC评审阶段测试人员应该注意哪些呢，该怎么做比较好呢？当遇到几十页几百页需求压下来的时候不好好整理一下真的很困惑。下面讲一下我个人认为在需求阶段能够起到明显效果的几点做法： 一、通读全文了解需求的目标 首先大概的浏览一下需求，大致了解一下整体的目标，要达到什么要求，与什么业务有关系，是全新的业务还是对某类老的业务进行改造等等。 二、仔细审阅每个功能点，寻找问题，理解需求 第2遍审阅需求需要非常仔细认真的审核每个功能点，使用鸡蛋里挑骨头的方式找出其中的问题或不理解的地方，记录下来。可以从系统角度考虑，从用户角度考虑，从测试人员角度考虑。比如系统可维护性，简单性，可测试行，易用性等等。 三、熟悉相关业务 如果是老业务的改版，需要是熟悉原来的系统，多操作老系统，熟悉各种业务，发现原来系统的优缺点，了解哪些地方需要优化，数据该如何准备，用列场景有哪些，心理有个数。从用户角度和测试人员的角度考虑问题，要改成什么样才认为更合理。如果是全新的业务，以前没有接触过的业务，需要查阅相关资料，了解同行的情况。 四、罗列出各功能点 从需求中整理出需要实现的功能点，哪些是本次要实现的功能点，哪些是以后需要实现的功能点。划分主次功能和优先级。 接下来需求评审的时候该问什么就问什么，把问题摆出来讨论，提出自己的建议。问题讨论如果没有结果记录下来下次需要再次评审，讨论出结果的记录讨论结果，会后要跟踪问题。 五、设计方案阶段，试着对一些模块进行设计 根据这些需求就测试人员也可以提前设计测试，画流程图之类的，甚至画草稿图都可以，形式不拘，这样就更进一步熟悉系统，测试人员需要对系统有一定了解，可以按照自己的思路设计，设计完成后可以和开发人员沟通和讨论自己的设计方案，使用各种反例来证明此方案是否正确，是否还有更简单的设计思路。 六、在设计方案评审前仔细审阅方案，看看一些异常情况下是否考虑到 另外开发人员的设计方案是否可行，一般正常逻辑都是符合的，可以从各种异常情况中来考虑此方案是否符合要求。 七、在设计方案评审阶段提出自己的见解 在设计方案评审的时候可以提出自己的方案和见解，看看是否可行，目的是为了找出更简单可行的方案。 八、记录评审问题，便于跟踪问题 评审中任何不确定问题都需要记录下来保存文档，便于跟踪问题。会后发送项目组成员。 当然这些自然要在项目前期投入较多时间才行，如果项目前期没有什么时间投入的话就另当别论了。