论目标

论目标

信息安全中经常需要验证一条信息,其做法是,定义一个函数f,f作用于信息得到一条简短的信息,即f(g(x),c) == f(h(x),c) == F 其中,g(x)是发送端的信息,h(x)是接收端信息,c是双方约定的一个信息,F是计算的结果,如果经过f作用后,得到的结果是相同,那么就可以认为,这条信息是真实的。

原理上这东西很简单,也非常实用,那么对应到不是信息安全领域中呢。

举个例子:

  1. 领导说,我们的当前目标是,在合法的范围内挣得一百万
  2. 所有人开始提方案
  3. 每个人根据目标,代入自己的方案,是否满足条件
  4. 如果所有方案都不能满足,和领导讨论是否tradeoff一部分要求

现在我经常性面对的问题是:

  1. 负责的人,提不出一个目标
  2. 执行的人,总能找到各种似是而非的理由,在一定条件下这又是成立的

举个例子:

  1. 提出做一个系统
  2. a提出A方案,方案A优点是1,2,3,4,5
  3. 但是大家都不同意,觉得这些操作相当冗余

那么这时候谁对谁错,作为一个负责人,这时候就要想到这么一个事情,这个事情的目标是什么:

  • A1,A2,A3,A4

那么上面的对错就容易判断了,如果a提出的1,2,3,4,5不满足A1,A2,A3,A4,一律是要砍掉,只保留能够满足A1,A2,A3,A4的设计

对应出来我们就得到了类似的和信息安全领域的结果即
f(1,2,3,4,5) == A1,A2,A3,A4
如此我们总能够简单的验证我们的工作成果,而不是陷入无止境的扯皮中

软件开发的三个层级

软件开发的三个层级

  1. 核心领域模型:该层级与实际业务应该一致,举个例子:我们在财务系统中有依据收款信息开票的选项,那么我们的领域模型就应该有个类叫做收款信息,它有一个动作叫做开票
  2. 领域模型对外的交互:到了这个层级,会有很多开源代码库帮助我们,例如我们需要发票对象需要对外暴露,那么通过mvc的形式,可以对外暴露发票的信息,或者是发票需要做持久化,有各种各样的Persistence的工具帮助我们
  3. 底层:例如数据库字段长度,报文的payload等等,到了这一层,应该是一个很具体的问题,具体来说,在这一层级不应该有任何业务相关的知识,而完全是计算机领域的知识

通过对软件开发进行划分层级,可以帮助我们开发过程中渐进式开发
比如我要关注业务代码的时候,就纯粹的业务思维,如果我是底层的开发,我只需要关注计算机领域的知识

为什么要这么划分

我在开发中观察到,大部分新手或者开发了很久的人,在写代码的时候,过早的关注到细节问题,比如写开发票的时候就开始关注到发票数据库字段长度,就直接陷进了细节中,具体对外表现出来就是业务实现统统一个函数打包,甚至还有全局变量等等
渐进式的分层开发有助于我们专注于一件事件,只有专注了,那么开发中错误才能减少

供应链系统开发(一)

供应链系统开发(一)

一些概念

  1. 四流
    1. 商流(以下三个角色通过商品物权转移就是商流)
      • 原材料商
      • 材料加工商
      • 成品销售商
    2. 物流
      • 商品的包装
      • 商品的运输
      • 商品的存储
    3. 信息流
      • 运输单据
      • 发货单据
      • 交易单据
      • 各种各样是的整个供应链能运行的单据成为信息流
    4. 资金流
      • 货款结算
  2. 四流合一
    1. 四流间联动
      1. 以物流与信息流相互影响为例
        1. 商品运输过程中若出现损坏
        2. 需要在运输单据中记录一条损坏商品的信息
        3. 当这个运输单据到达货主处,货主要根据单据来验收,从而得到应收数量减少

    那么四流合一就很明白了,四流的内容能够完全反映出整个供应链链条的运作
    即四流可以与一条供应链等价

  3. 为了实现四流合一,又提出了三库的说法

    1. 供应商库
    2. 采购商库
    3. 商品库
  4. 为了提高整个供应链商品的运转效率,这时候需要有个服务商使得三库的链条运转顺畅得到了以下
    1. 服务商库
      1. 资金
      2. 物流

供应链系统开发(二)

供应链系统开发(二)

基本要素(确定调研方向,即确定参与系统的角色)

  • 上游供货商
  • 下游采购商
  • 资金提供商
  • 商品
  • 信息掮客/平台

以上是构成现代供应链的几个基础要素

要达成交易需要的几个步骤(业务流程分析)

  1. 下游采购商提出采购商品
  2. 下游采购商提出用款需求
  3. 下游采购商提出指定供货商/或者不关心
  4. 平台发布信息
  5. 平台撮合商品
  6. 平台撮合资金需求
  7. 平台撮合供应商

如下故事可以将场景闭环(业务场景分析)

  1. 客户向平台提出采购需求
  2. 平台分析需求,若仅有采购需求(直营)
    1. 从自有平台信息中寻找可撮合的交易对象
    2. 若存在则撮合交易
      1. 平台与供货商确定配送方式
      2. 客户付款
      3. 平台确认付款后,通知/直接将货物配送到指定地点
      4. 平台通知客户提货
      5. 客户通知平台提货完成
      6. 三方票据结算
      7. 故事结束
    3. 若不存在则
      1. 与客户沟通让其提供参考供应商
      2. 平台考察客户提供供应商,若准入则添加供应商至平台信息返回故事2.1
      3. 若不允许准入,则故事结束
  3. 若还有融资需求(垫资代采业务)
    1. 从自有平台信息中寻找可撮合的资金提供商
      1. 若存在则撮合交易
        1. 平台与资金提供商确定资金占用费用
        2. 平台与资金提供商确定供应商是否准入
        3. 平台与资金提供商确定商品是否准入
        4. 平台向客户返回费用协商结果及供应商,商品准入结果(项目信息)
        5. 若客户同意项目结果,则签署合同返回故事2.1
        6. 若客户不同意则返回3.1继续执行,直到所有资金商都无法满足客户需求
    2. 若无,则故事结束

到了这一步则系统的概设完成

参与角色与参与要素(业务场景涉及的表单、文件、票据等分析)

对照直营故事来细化
1. 询价单
2. 供应商目录
3. 商品目录
4. 采购合同
5. 销售合同
6. 采购订单
7. 销售订单
8. 发票
9. 通知
对照垫资代采故事细化
1. 资金提供商目录
2. 项目信息
3. 垫资代采合同
4. 与客户确认单据
按照此思路逐项分析,直至形成一个业务需求文档