假设您现在有一个用于创建订单的界面：
public ordercreateresultdto createorder(ordercreatedto order)创建订单对象。
public class ordercreatedtoOrder 响应对象。
public class ordercreateresultdto现在业务发生了变化，产品经理需要：创建订单时不需要 C 和 D 字段，并添加了 E 和 F 字段。如果你是一名开发人员，你会如何设计这个界面？一种幼稚的思维方式是删除 c 和 d 字段并添加 e 和 f 字段
创建订单对象。
public class ordercreatedtoOrder 响应对象。
public class ordercreateresultdto让我们考虑一下这是否可行答案是否定的，原因有三：
第一个原因是接口的契约性：接口暴露给本服务的外部使用，相当于上下游签订合约，如果随意修改合约，那么合约的严肃性就没了。
第二个原因是版本兼容性我们知道应用是有版本号的，假设应用版本 1 使用初始界面，那么应用版本 2 由于新业务需要使用新界面，但你不能直接更改初始界面面目全非，因为应用版本 1 在使用的用户很多， 如果只考虑新版本，旧版本将报告错误。
第三个原因是时间窗口我们知道应用发布版本需要审核，即使这个版本是强更新，也会有新特性和旧特性并存的时间窗口，所以在升级时一定要考虑服务器接口。
既然不能直接升级，这个问题应该如何解决呢？我认为有两个方面需要考虑：
分层维度。 拆分维度。
在第一种结构的实践中，可以分为多层，但核心仍然是三层，我们分析每一层如何适应界面变化
数据层。 业务层。
表示层。 由于新旧版本并存，数据层必须保留旧版本和新版本中的所有字段，并将旧字段标记为已过时，但您需要更改该字段是否为必填字段，因为该字段的某些旧版本变得不必要
public class ordercreatedo业务层是承载核心业务的层，因此包含大量的业务逻辑，有两种解决方案：
解决方案 1：添加新的业务对象并重写业务方法
解决方案 2：修改业务对象以适应业务方法
方案1的优点是不耦合旧业务，但缺点是只有一小部分新旧方法的逻辑可能不同，因此需要将大量逻辑从旧业务方法复制到新方法中。
方法二的优点是旧逻辑可以复用，缺点是新旧逻辑耦合，如果适配逻辑处理不好，可能会影响旧逻辑。
因此，两种方案各有各的使用场景，第一种方案适用于业务逻辑变化较大的场景，并且由于是重构，因此可以重新声明新的业务对象
public class ordercreatenewbo方案 2 适用于业务逻辑微调场景，因此旧业务对象需要包含新旧字段将旧字段标记为已过时：
public class ordercreatebo表示层不应该处理复杂的业务逻辑，而应该根据业务对象进行定制和调整，这样它就可以添加了新版本的 API，没有业务层的负担：
创建订单对象。
public class ordercreatedtov2Order 响应对象。
public class ordercreateresultdtov2但是，如果表示层没有标准化，包含大量业务逻辑，那么思维方式与业务层相同，还需要使用选项2。
一个系统在业务上通常分为三端：
面向 B 端用户。
面向 C 端用户。
对于操作用户。
这三个方面都有一个 BFF 层，但实现技术通常不同：
B面和C面有一个应用程序。
通常 H5 是为操作员实现的。
因此，如果没有APP，为了防止界面变得越来越臃肿，BFF层对于操作用户可以考虑删除旧字段。
为什么需要生物思维 这本书提到了复杂系统形成的四个原因：
吸 积。 挨次。
必须处理的意外情况。
一个常见的稀有事件。
字面阅读可以理解为一个过程吸附和积累。就像一粒沙子，一次添加一点点，最终聚集成一座沙山。 在软件开发的世界里，无论每次迭代在表面上看起来多么独立和微不足道，它们都在客观上为数量的增长做出了贡献。
吸积效应导致**变得如此庞大和复杂，以至于没有人能够完全掌握这个系统。 当系统出现问题或故障时，最熟悉**这部分的人可能早已离开，消失在人海中。
面对这种情况，开发人员往往不得不添加一段兼容性逻辑，以减少对遗留系统的影响。 然而，这种方法恰恰相反加剧吸积效应。即使在一些绝望的情况下，团队也可能被迫选择容忍某些错误，因为修复它们的成本远远超过容忍它们的风险。 这是增值在软件开发中带来的巨大挑战。
技术系统是朝着熵增的方向发展的，从有序到无序，所以工程师需要通过一些手段来减缓这个过程，常见的方案是：
统一的技术架构。
技术规范的统一。
统一您的业务语言。
*分享和评论。
技术与业务共享。
系统稳定性建设。
作者： J**A Front.
友情链接： juejincn/post/7308218421715140659