概要设计心得 kaki的博客

概要设计背景：

     1.由于我们的上游C系统的解耦重构一系列优化， 使得我们B系统也要进行配合优化。

     2.C 系统 采用的是EGL,COBOL 等语言编写，数据库使用DB2。本次C系统将部分功能逻辑使用Java语言及相关框架过渡开发。

     3. B系统 采用JavaWeb模式，2020年做过Maven 重构，B系统较为庞大，其子系统包括（从B系统衍生出来的系统，非JavaWeb 系统 ），Kafka节点子系统，ATM节点子系统，移动端节点子系统等。

     4.本次我方涉及配合改造内容是消息队列节点。

     原消息队列模式：

      C系统将消息推送至IP网关（老模式2001款），我方B系统主项目启动后会有个专门监听IP网关的一个功能，当C系统推送消息到IP网关后，我方可实时监听到消息，并对消息进行处理。

      

 

     新消息队列模式：

     C系统在Java Spring 平台生产消息，将消息存入到一张数据表中（Mysql 表），C 系统的Kafka节点会监听该表的变化，当有数据插入或者更新，Kafka 的消息生产者就会将消息推送至 Kafka 消费者群主。我们B系统只需要在我方的Kafka消费者节点配置上Topic等相关信息可以获得消息推送

     

 

详细设计分析：

  源消息格式：

    100000000000@@00000000000  E111F-SGA 999999 00200009980105431

  第一步： 我们先假定C系统消息是这样的，该消息的获取方式为，先做一笔旧就交易获取。

  第二步： 分析我们B系统原程序处理流程，及其分支的多种情况，这些情况需要列举在概要设计中，并告知C方。

  第三步： 分支我方系统的kafka 消息接收方式。当了解了我方的kafka消息接收方式后，分析如何与我方系统进行消息的传递（注：由于系统原因，我方B系统 Java Web 项目未接入Dobbo 方式，但2016年我方对B系统进行增幅，建立了一个子系统（B-Service）,该系统可以与B系统进行Http，XML的方式进行消息传输）。

 第四步：B-Service 作为 B系统的对外代理系统，起到了承上启下的作用。

    问题1：为什么不直接在B系统直接接到Dobbo服务？

    答：B系统过于老旧，系统内容庞大，相关功能追溯至九几年，不易于较大改动。

    问题2：为什么不直接用Kafka 消费者节点与B系统直接进行Http,XML形式的信息交互。

    答：安全起见，B系统设计到很多账务信息，所以建议在外部设置一个代理系统。

 第五步：最终定稿，将流程图绘制出来。

   

 

  第六步：撰写概要设计，将思路与上层架构师进行描述，方案评审。与需求提出者进行交谈，然后最终定稿，实现。

心得：

   1.态度：

       对一个需求而言，设计者要从需求提出者的角度思考问题，同时设计者要从开发人员的角度考虑问题。思路一定要清晰，明确自己下一步要做什么，以及设计进度的把握。

   2.沟通（communication）：

      要善于沟通，无论与上游C系统负责人，还是与B系统的开发人员，都要进行沟通。拿出敏而好学，不耻下问的精神。语气平和，勿急躁。一旦遇到自己解决不了，或者困惑的事情及时与自己的上层领导进行沟通。

                   面对面沟通   ＞  电话沟通  ＞ 办公通讯软件沟通 

      注： ＞ 为 大于号

      本次是我第一次写概要设计

   

 

欢迎关注kaki 的码云，以及B站 KakiNakajima

码云直通车