技术管理 | 为什么业务一变,你的技术方案就废了?
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
TechLead 少个分号
扫码关注公众号
扫码阅读
手机扫码阅读
文章主旨:
从技术与商业结合的角度,分析如何设计技术方案以减少废弃率,强调理解业务背后的商业逻辑是关键。
关键要点:
- 技术方案废弃的根源在于缺乏对业务需求背后商业逻辑的深刻理解。
- 软件设计的四层次:皮肤(界面)、血肉(业务逻辑)、骨骼(领域模型)和灵魂(商业模式)。
- 领域模型设计要兼顾扩展性与稳定性,避免过于简单或复杂,必要时申请重构。
- 业务流程与用例是最容易变化的部分,应以灵活配置和解耦设计应对频繁变化。
- 界面设计变化频繁,应通过主题配置与组件化设计减少重构成本。
内容结构:
一维看二维,二维看三维
技术方案容易被废弃的原因在于技术人员通常只从表面需求出发,忽略了业务背后的逻辑和目的。通过类比纸张观察立方体的例子,作者指出只有深刻理解“商业模式”才能设计出适应长期变化的技术方案。
软件的皮肤、血肉、骨骼、灵魂
作者将软件比喻为人,分为四层设计内容:
- 皮肤:界面样式、颜色、字体等,最容易变化。
- 血肉:业务逻辑和流程,变化频繁且需灵活支持。
- 骨骼:领域模型,需考虑扩展性和稳定性。
- 灵魂:商业模式,决定系统的根本设计逻辑。
灵魂与骨骼的变动
商业模式的改变通常导致骨骼层面的重构需求。作者举例说明新项目灵魂变动时,若骨骼未进行相应调整,系统容易陷入补丁堆积的困境,建议申请预算进行彻底重构。
血肉和皮肤层的设计建议
对于业务流程和用例的设计,作者建议通过流程图和配置驱动提高灵活性,同时强调记录版本差异以便未来维护。界面设计则通过主题配置与组件化减轻频繁变化带来的工作量。
结语:懂商业,才能写不容易废掉的代码
技术人员需要理解业务的商业模式和改动的战略意义,只有这样才能设计出适应长期需求的技术方案,避免陷入重复修补的困境。
文章总结:
文章强调技术人员在设计方案时需深刻理解业务背后的商业逻辑,建议通过灵活设计、扩展性支持和重构申请应对技术废弃问题。
TechLead 少个分号
TechLead 少个分号
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
TechLead 少个分号的其他文章
理解 DDD:编程中的模型思维
业务设计上往往没有建立起特定的领域模型,这是我们架构腐化和软件开发困难的关键原因。**业务领域建立好的模型,并指导代码实践,这就是 ”编程思维“。** DDD 领域驱动设计就是解决这部分问题,与其叫领域驱动设计,不如叫做模型驱动设计。
技术管理 | 如何分析和影响你的干系人?
干系人管理是一项很硬的软实力,由干系人管理带来价值可能比很多开发人员加班合起来还大。
使用概念图梳理编程中的概念
概念图节点是概念,概念是认知世界的元素,按照诺瓦克定义来说,就是给印象中的事物打一个标签。
系统设计 | 对象转换方案
如何轻松地转换和映射 Java 对象?
系统设计 | 应用、微服务、流程、规则编排
分析常见需要编排的场景,辨析应用、微服务、流程、规则编排。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线