软件设计、DDD概念及落地时的一些零碎思考和记录2

主要是项目中一些落地经验和记录

技术人员、开发人员

• 大部分程序员真的不善于沟通，经常会显得很保守；
• 他们技术上的困惑、误解乃至郁闷都很难直接的表达清楚；
• 他们对自己的错误“印象”很深；
• 他们内心是希望提高、改进，出自各种目的，也包括为了轻松点或者“牛逼”点，这属于优点；
• orm已经是一种现实的基础能力；

推进者

• 类似技术经理和技术组长这种直接面对程序员的职位必须有技术要求，如果发现他们不符合要求，需要警惕；
• 技术和设计理念的推进者必须有技术能力支持；
• 推进者无需成为心理专家，但要有从代码中发现问题的能力（并非bug，是员工在技术上存在的缺陷和问题或者原有技术栈的痛点）；
• 在落地这个环节上，团队就是是需求方，程序员就是领域专家，请保持尊重并勇于面对；
• 尊重传统，团队中已有的名词如果没有重大冲突不要轻易变更，可以作为落地领域的领域语言基础；
• 推进的目的是效率和质量，团队外部的压力也通常来自这里，而团队内部还会有其他想法，需要考虑如何平衡内外，保持一定的弹性；
• 推进不能影响进度，分步推进，给团队一些消化时间；
• 如果不能说明新东西能解决的实际开发问题，不要推进；
• 推进者需要更多付出
• 如果失败，除非有着买彩票中大奖的运气，“奇葩成员的奇葩行为导致失败”不是理由；
• 自用系统是更好的切入点

从application开始

• 名词不重要，有时接口服务之类的更容易被接受；
• 流程组装
  大部分程序员对流程都很有概念，大部分客户对流程的进度都很感兴趣，然而很多情况下流程出于各种原因（能力、事务需求）会被藏在业务逻辑的处理之中或者被“顺手”处理了，很多时候组装甚至会发生在前端站点；
  提供一个总览式的统一的流程组装位置，难度最低、最安全、最直观、最简单；
• 事务时机
  通常事务会发生在流程处理的某个或某几个环节上，所以在流程组装时提升事务处理时机就会变的比较自然；
• 尽量满足前端站点的一些需求
  前端的需求变化非常多，需求方对于需求变化有着自己的考虑， 很多时候他们会认为前端变化比较简单；
  很多时候为了保证业务逻辑处理没有过大的变化，会“支付”一些前端需求；
  有些需求变化实际上会涉及到一些流程节点（技术层面）的调整甚至流程的重新组装，这种是需要尽量满足的；
• 流程组装能够消化一部分需求变化，事务时机能够引导程序员更好的思考存储；
• 即使不引入其他任何概念，一个结构良好的易读易用的日志系统是必须的；

业务逻辑 domain

• io类的处理尽量分离；
• 如果要处理历史宝藏，if switch哥俩好放最后；
• 仓储对orm的隔离不是必须的；
• 复用范围定在本项目之内；
• 如果你的项目已经复杂到需要隔离查询， 有可能的话拉一把；查询端也已经消化了一些需求了；
• 不要一个人处理
• 管理后台对业务线、某些写入需求应在此处理，注意区分与前端需求的异同；
• 时间、时刻，同步、异步
• 根据具体项目确定粒度原则
• 注意缓存

基础设施、框架

• 云端通常没有宣传的那么可靠；
• 网络永远都是问题；
• 监控是分布的头等大事；
• redis这种功能多的容易被接受；
• 只要有合适的场景，mq非常容易被接受；
• 稳定压倒一切；
• 数据需要清理；
• 框架以支持服务为主，限制性的东西不要多
• 安全
• 时间时钟