摘要：
前言 本文基于报销单模型进行团队级别是ddd设计 报销单需求、背景 草稿状态 提交状态 退回场景 会议一：统一建模语言 统一语言： 头脑风暴，获取知识，画概念图，画用例图，找深层模型； 我们可能需要一种模型，专家和我们都能看懂的，而且讨论问题就以模型为沟通语言的核心。我们需要保持2点： 绑定这个核心 阅读全文
摘要：
本人发布到阿里开发者 《领域驱动设计》：从领域视角深入仓储（Repository）的设计和实现 阅读全文
摘要：
知识体系驱动设计 如何指导你的设计，在DDD看来是领域知识驱动，但是比起DDD更提升一层的理念，应该是知识体驱动设计。 第一件事，对领域进行充分的理解，其实统一语言就是为了帮助软件开发软件去理解知识的，本质上是一种软件开发者获取知识的交流手段 第二件事，是对问题本质的思考，对问题本质的思考，意味你需 阅读全文
摘要：
前言 不要指望系统是好的，代码重构是第一步，但是系统重构是目的，从系统维度看重构的战略和战术设计。 重构的价值：业务和产品是不感知重构的，上级领导可能是未知的，所以重构难以被排期 当前场景重构：重构需要针对场景重构，主要是避免过度设计，场景梳理是需要时间的，但是当前要做的项目是最好的切入点 历史场景 阅读全文
摘要：
点击进入：《领域驱动设计最佳实践》 阅读全文
摘要：
稳定性： 以下属于稳定性考虑的事情： 为什么需要各个维度的指标呢？ 因为其实问题出现的话，肯定是有连锁反应的，我们也有根据发现的表象立即分析出问题的根因，并且需要评估其影响，做最合理的应对方案。 事前： 掌控：必须要有对代码的掌控、对技术栈的深入了解，特别对于复杂的业务，在垃圾堆里面找bug或许需要 阅读全文
摘要：
前言： 领域驱动设计，是一种架构思想，它不是关于技术的，而是关于讨论、聆听、发现和业务价值的，而这些都是为了把知识挖掘并表达出来。 敏捷开发：DDD并非充满繁文缛节的笨重的开发过程，相反它可以和敏捷很好的结合。可以采用“测试先行、逐步改进”的设计思路。其中重构是最必要的一步。 领域： 领域分类：可以 阅读全文
摘要：
概念 服务提供者：服务注册方，被调用方直接调用，服务应该是有状态的，基于ip+port，需要探活 服务消费者：服务调用方，从注册中心获取服务提供者ip，直接调用 注册中心：服务提供者注册、服务提供者注销、服务提供者保活； CAP：在服务发现方面，A是大于C的，读一致性不需要强一致，是系统可接受的 软 阅读全文
摘要：
分布式ID 要保证id不重复，主要从三方面考虑，时间维度、空间维度、原子维度； 时间维度：时间维度不重复，例如今天和明天不能重复，所以时间是可以加入id的一种因子； 空间维度：不同的机器，不同的环境生成的id不同，所以mac地址，机房地址等，都可以作为空间维度的区分； 原子维度：主要是线程的安全性， 阅读全文
摘要：
量： 人们在实践活动中，为了从量的方面研究事物运动、变化的规律性，或者事物之间的数量关系，必须舍弃事物的具体内容，而从事物的量的规律性中抽象出数的概念。这种抽象最初是通过把握事物运动的联系的静态过程所达到的，这种考察事物的方式反映在数学上就产生常量的概念。 数与量：数是值，量是量度，数量是某种抽象纬 阅读全文