首页
学习
活动
专区
工具
TVP
发布

斑斓

张逸的技术分享
专栏作者
256
文章
255977
阅读量
60
订阅数
全面分析和理解PBC
2021年,Gartner给出2022年Top Strategic Technology Trends,列出的12项前沿技术中,包括了组合式应用(Composable Applications)。同时,Gartner预测,到2024年, 新的SaaS应用和自定义应用都将是“composable API-first or API-only”。这种可组装API优先或API唯一的方式,甚至可以认为是现代应用的一种特征,可以概况为开放和组合。
张逸
2023-03-23
2.6K0
微服务已经大势不在?
受宠的微服务火了这么多年,没想到被一个不懂软件研发的马斯克戳破了越来越膨胀的气球。
张逸
2023-03-23
6500
DDD实战之六:战略设计之技术决策
特别说明:我在写这篇的过程中,发现前面第四、五篇的上下文识别和关系映射中一些错误:将“确认订单付款”和“确认接龙付款”错误的合并为一个用例“确认购买并付款”(其实应该是包含子用例“创建付款订单”),并且相应的跨上下文用例中也遗漏了“确认接龙付款”。
张逸
2023-03-23
4650
调整限界上下文边界
说是前情回顾,由于我许久不曾更新此系列文章,在这新旧之交的年初,真可以说有两年这么漫长了。虽然是我的忙导致了文章更新的荒废,但归根结底,其实还是我的惫懒在作怪。人的心弦总不能一直崩着,忙活了一年,总要适当放飞一下自己,到了春节,怎么也得放松一下吧。于是,更新文章的日程就一推再推,即使有读者不断催更,我也拖着,装着没听见,不理睬。
张逸
2023-03-23
1870
架构设计的三个原则
一致性是软件架构质量原则的根基,遵循一致原则的软件架构可以有效地保证整个架构解决方案的清晰直接,降低了解决方案的复杂度。尤其对于一个大规模系统,往往需要多个团队共同开发完成,如果不遵循一致原则,就会导致整个平台的建设缺乏完整性和规范性,各个子系统各自为政,业务功能重复开发,技术实现五花八门,服务集成复杂低效,信息冗余制造出知识壁垒。
张逸
2023-03-23
4710
构建领域驱动设计知识体系
本次演讲是我创作GitChat课程「领域驱动战略设计实践」和「领域驱动战术设计实践」这两年来,随着对领域驱动设计的深度理解,结合自身项目经验总结的领域驱动设计知识体系。
张逸
2019-12-05
1.3K0
构建领域驱动设计知识体系
本次演讲是我创作GitChat课程「领域驱动战略设计实践」和「领域驱动战术设计实践」这两年来,随着对领域驱动设计的深度理解,结合自身项目经验总结的领域驱动设计知识体系。
张逸
2019-12-05
1.3K0
噢,你的代码像一坨翔。然后呢?
陶文,ThoughtWorks毕业生,从事过软件开发,敏捷咨询,项目管理,测试研发,运维平台等多个领域的工作。曾任滴滴出行平台技术部首席架构师,现从事滴滴的平台治理和客服系统的改进工作,致力于为大家提供一个更好的出行生态。
张逸
2019-08-22
9870
从单体架构到微服务架构
我在Martin Fowler网站上读到一篇名为How to break a Monolith into Microservices的微服务文章,作者为ThoughtWorks的咨询师Zhamak Dehghani,介绍了如何从单体架构演进到微服务架构。
张逸
2019-08-21
6360
从单体架构到微服务架构
我在Martin Fowler网站上读到一篇名为How to break a Monolith into Microservices的微服务文章,作者为ThoughtWorks的咨询师Zhamak Dehghani,介绍了如何从单体架构演进到微服务架构。
张逸
2019-08-21
6360
微服务一点都不“微”
通过这几年在项目中实践微服务,为客户提供微服务咨询,我越来越发现所谓“微服务(Micro Service)”其实一点都不“微”!这非Martin Fowler定义之过。他所定义的概念,突出了设计每个独立服务时要分解的粒度,但对于整个架构风格而言,实践微服务并不如概念所表现的那样举重若轻,然后轻而易举。一个微服务从诞生到最后的消亡,经历了设计、开发、测试、上线、运行到下线贯穿始终的生命周期。每个环节都有方方面面的因素需要考量。诸如设计原则的遵守、通信机制的选择、数据一致性的保障、健康状态的监控与跟踪,乃至于服务的配置、测试与运维,更何况还需要对企业的组织结构进行改革,遵循康威定律组建团队使之与微服务架构风格相匹配。
张逸
2019-06-20
5180
微服务一点都不“微”
通过这几年在项目中实践微服务,为客户提供微服务咨询,我越来越发现所谓“微服务(Micro Service)”其实一点都不“微”!这非Martin Fowler定义之过。他所定义的概念,突出了设计每个独立服务时要分解的粒度,但对于整个架构风格而言,实践微服务并不如概念所表现的那样举重若轻,然后轻而易举。一个微服务从诞生到最后的消亡,经历了设计、开发、测试、上线、运行到下线贯穿始终的生命周期。每个环节都有方方面面的因素需要考量。诸如设计原则的遵守、通信机制的选择、数据一致性的保障、健康状态的监控与跟踪,乃至于服务的配置、测试与运维,更何况还需要对企业的组织结构进行改革,遵循康威定律组建团队使之与微服务架构风格相匹配。
张逸
2019-06-20
5180
领域驱动战略设计暨微服务设计工作坊
在2018年第二届领域驱动设计中国峰会,我作为讲师做了一个领域驱动战略设计工作坊——再现具有实操价值的架构方案。在这个工作坊中,我将敏捷实践中的Inception与领域驱动战略设计结合起来,并引入Event Storming和用例场景分析等方法,带着大家一起糊了墙,玩风暴,算是满意地完成了战略设计的预期目标。在这次工作坊的参与者中,我欣喜地看到了业务同学的加入。这些业务同学敏锐的分析目光与业务感给我们的用例场景分析带来了极好的助力,也为整个工作坊增加了不少亮点。
张逸
2018-12-29
8260
基于Spring Cloud的微服务落地
微服务架构模式的核心在于如何识别服务的边界,设计出合理的微服务。但如果要将微服务架构运用到生产项目上,并且能够发挥该架构模式的重要作用,则需要微服务框架的支持。
张逸
2018-07-27
5250
基于Spring Cloud的微服务落地
微服务架构模式的核心在于如何识别服务的边界,设计出合理的微服务。但如果要将微服务架构运用到生产项目上,并且能够发挥该架构模式的重要作用,则需要微服务框架的支持。
张逸
2018-07-27
5250
解惑领域驱动设计的若干问题
作者 | 张逸 最近重读Eric Evans的经典《领域驱动设计》,正如Eric提倡我们要去发现隐式概念一般,这次重读也让我发现了许多隐藏的DDD知识。恰好今日有朋友咨询我一些DDD问题,好似激活了触发器,随着问题的解答,我倒是在回答过程中又把这些知识梳理了一遍,才有了这篇杂记。 问题一:Repository的问题 怎么看待DDD中的Repository?我们必须把握一个根本的底线,就是采用DDD方式设计Repository时,一定要忘记所有与数据访问有关的技术实现细节。Repository接口属于领域层
张逸
2018-03-29
9720
解惑领域驱动设计的若干问题
作者 | 张逸 最近重读Eric Evans的经典《领域驱动设计》,正如Eric提倡我们要去发现隐式概念一般,这次重读也让我发现了许多隐藏的DDD知识。恰好今日有朋友咨询我一些DDD问题,好似激活了触发器,随着问题的解答,我倒是在回答过程中又把这些知识梳理了一遍,才有了这篇杂记。 问题一:Repository的问题 怎么看待DDD中的Repository?我们必须把握一个根本的底线,就是采用DDD方式设计Repository时,一定要忘记所有与数据访问有关的技术实现细节。Repository接口属于领域层
张逸
2018-03-29
9720
当DDD遇上微服务
DDD与微服务是可以相通的,其关键在于Bounded Context。 分布式系统的定义 在谈论这个之前,我们需要就什么是分布式系统达成一致。在我看来,判断一个系统是否是分布式的,其标准是看系统中是否存在跨进程通信。是进程决定了协作与通信的方式,从而引申出两种具有本质区别的编程模型: 进程内编程模型 跨进程编程模型 它们之间的区别在于组件之间的调用方式。进程内的组件调用是非常简单的,就Java而言,各个驻留于同一个JVM的对象与变量都放在堆内存或者栈内存中,对象的调用(包括方法的调用)就是一种内存的寻址。
张逸
2018-03-07
1.2K0
限界上下文的边界
边界通过限界上下文来确定,这在领域驱动设计中具有非凡的意义。对应于通用语言,限界上下文是语言的边界,对于领域模型,限界上下文是模型的边界,二者对应于问题空间(Problem Space)的界定。对于系统的架构,限界上下文还确定了应用边界和技术边界,进而帮助我们确定整个系统及各个限界上下文的解决方案。可以说,限界上下文是连接问题空间与解决方案空间的重要桥梁。 那么,限界上下文所界定的边界,究竟是逻辑边界,还是物理边界?这并没有定论,需得依据不同场景而做出不同的决策。 逻辑边界 根据业务对领域进行逻辑分解时,
张逸
2018-03-07
1.4K0
限界上下文的边界
边界通过限界上下文来确定,这在领域驱动设计中具有非凡的意义。对应于通用语言,限界上下文是语言的边界,对于领域模型,限界上下文是模型的边界,二者对应于问题空间(Problem Space)的界定。对于系统的架构,限界上下文还确定了应用边界和技术边界,进而帮助我们确定整个系统及各个限界上下文的解决方案。可以说,限界上下文是连接问题空间与解决方案空间的重要桥梁。 那么,限界上下文所界定的边界,究竟是逻辑边界,还是物理边界?这并没有定论,需得依据不同场景而做出不同的决策。 逻辑边界 根据业务对领域进行逻辑分解时,
张逸
2018-03-07
1.4K0
点击加载更多
社区活动
腾讯技术创作狂欢月
“码”上创作 21 天,分 10000 元奖品池!
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档