架构产品
文章平均质量分 70
以后要学会自己成长了,首个技术上层的专栏
飞奔的大土豆
今天最好的表现是明天最低的要求
未来早已到来,只是还未普及
展开
-
GPT3年终总结
技术深度与架构设计: 强调在过去一年中深入参与的技术挑战,包括设计和实施复杂系统的能力,技术决策的成功实践,以及对新技术趋势的敏锐感知。通过更具体和详细的表述,中级架构师的年度总结可以更全面地展示其在技术和领导力方面的成就,并为未来的职业发展提供更有针对性的方向。技术愿景和趋势: 强调对技术领域趋势的洞察力,以及如何将这些趋势整合到组织的技术愿景中,确保技术架构的未来可持续性。风险管理和决策: 讨论中级架构师在技术决策中的角色,包括如何识别和管理技术风险,并做出符合组织利益的决策。原创 2023-12-04 13:04:14 · 832 阅读 · 0 评论 -
一个失败架构升级案例
失败的架构升级案例原创 2023-10-20 20:27:16 · 880 阅读 · 0 评论 -
实战总结|复杂系统设计原则与案例
本文主要讲述了应对复杂性的一些原则和经验,通过实际案例解构设计思想,个人认为好的设计是体现在「职责分离」、「抽象分层」和「变化扩展」上,在类的结构设计上尤其要花心思去想,如「变与不变分离」、「配置域与执行域分离」、「查询与命令分离」。转载 2023-07-18 08:56:12 · 83 阅读 · 0 评论 -
ddd与微服务思考
在从业务模型向微服务落地的过程中,即从战略设计向战术设计的实施过程中,我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系,将业务架构和系统架构进行绑定。因此,通过领域驱动设计的战略设计和战术设计,我们可以清晰地划定领域边界,建立领域模型,帮助我们实现微服务的设计和拆分,同时也能够有效地响应业务变化,提高软件开发和落地的效率。在 DDD 中,我们关注的是业务领域的划分和领域模型的设计,以便更好地理解业务需求,并将其转化为可执行的代码。我们可以用三步来划定领域模型和微服务的边界。转载 2023-07-12 09:10:31 · 101 阅读 · 0 评论 -
从零开始的领域驱动设计
背景:工作驱动,公司做新系统,同事采用DDD架构模式设计,因为除了参与功能设计外,归根还是要参与业务设计,就此学习下领域驱动,网上发现了ali中间件工程师文章,描述很接地气,传送linkhttps://blog.csdn.net/u013815546/article/details/76223449之余也记录下自己的理解几个点; 结合领域驱动设计,更加让我确定,技术方案始终有代替方案,决定微服务的不是框架的选择,不仅仅是restful或者rpc的接口设计风格的抉择,而更应该关注拆解,领域,限界上下文,聚.转载 2021-07-05 00:27:44 · 151 阅读 · 0 评论 -
记关于SaaS平台中应对多租户模式的设计
用了多年的权限管理模型,今天才知道有正规RBDC设计思想 ,知识不系统化的结果,mark;也是从合同附件里面看到saas多租户设计 才具体了解其概念,了解的越多发现懂得越少另外关于权限设计: 关于SaaS平台中应对多租户模式的设计—权限设计 自己感悟:待续 这几年,在公司尝试转型做产品。所以引入了很多的产品的理念。不管是对产品的定义,还是针对产品的管理,以及摸索产品的落地等等。我之前更多的是接触的ToB端,所以想必也猜到了是一个SaaS模式的产品。其实,现在回想并总结,之前所做的产品并不理想。当然,在转载 2020-06-26 16:57:09 · 1190 阅读 · 0 评论