架构设计知识体系
文章平均质量分 81
分布式微服务架构设计知识体系
ElonZhao
这个作者很懒,什么都没留下…
展开
-
系统设计方法论4-综合大数据分析和营销场景
阅读引导: 1、科技引领业务,需要从系统设计开始考量。 2、考虑业务数字化后,再通过CMTRO方法数字业务化反向推动业务。 3、有时需要考虑营销的场景,提前规划 “科技引领业务”。 对科技开发人员来说,最基础的工作是实现功能需求,支撑业务。 但是,这样的话,科技人员真的成了搬砖的”民工“了。 根本无法体现科技人员的价值,也无法赢取业务、市场等人员的理解与尊重。 科技改变世界,并不是一句空话。 虽然我们身处的行业,做的只是业务交付,不是高精端技术,没有去SpaceX造火箭,也没有去做脑机接口,但是,我们完.原创 2021-04-15 22:42:58 · 164 阅读 · 0 评论 -
2021-04-15
阅读引导: 1、系统设计,首要考虑的是完备性,非常考验设计人员的逻辑思维能力,本文提供一个思维框架。 2、设计人员可以借鉴的开源优秀产品设计思路,典型的如Spring、Dubbo 通过上一篇的方法找出主干之后,就像是造人已经有了骨架。 还需要填充血肉。 包括五脏六腑、奇经八脉等……以及如何点亮生命之火。 实际上,设计系统也需要在抓住骨干之后,再去多维度的填充细节。 那么问题就是,到底从哪些方面去填充细节? 不同的系统,对应着不同的业务场景,有没有一种通用的思考框架呢? 当然有。 我称之为CDLC(Cor.原创 2021-04-15 22:41:46 · 108 阅读 · 0 评论 -
系统设计方法论1-拧干水分,竖切需求
系统设计方法论1-拧干水分,竖切需求 1、如何成为别人眼中“既懂业务又懂技术”的大牛? 2、怎么才能听完需求后,马上提出完善的方案,让业务和开发都叹服? 3、程序员的核心竞争力以及“护城河” 在程序员的乌托邦世界中,产品经理或者业务人员,能够精准的描述出来所有的产品功能、需求条目以及逻辑处理流程。 然后,程序员只需要按部就班的开发,就可以了。 可惜,这只是白日梦。 也幸好这只是白日梦,否则程序员马上就会被机器替代。 所有程序员都憎恨需求的频繁变更,尤其是在到了开发的中后期。 因为,修改设计方案的代价非常原创 2021-02-17 20:39:37 · 324 阅读 · 3 评论