垂直切片参考框架

Question

我们最近经常听到“垂直切片”的概念。我认为我们在创造更小、更清晰的故事方面做得更好。当我搜索垂直切片的信息时，没有人定义他们的系统有多大。例如，我看到Adobe与山山羊软件签订了合同，提出了一个垂直完成特性的解决方案，甚至跨几个团队。

关于我的更多信息，我的背景是在一家大公司里，团队负责某些后端系统，我们必须至少完成两次冲刺，才能把事情作为一个“特性”来完成--其他系统的后端工作，以及我们系统的集成工作。我的观点是，在该公司的垂直切片参照系在某种程度上是‘项目’水平。一个项目可以是一套完整的数据库、后端服务器、后台服务、消息队列/处理等，但它是围绕一个中心公司项目定义的。

例如，我们面向客户的web应用程序有多个数据库，它从其他项目将信息放入的几个数据存储库中提取出来，有批处理应用程序每晚运行、从多个消息队列读取和写信，以便向客户发送电子邮件等。即使有了所有这些，所有的“可交付功能”在“项目”中都是垂直的。堆栈通常是:客户机、->、web服务器、->数据库或web服务。

在新公司，我们有一个相当混乱的项目网络，只有几个devs (我在我的团队中有更多的开发人员在上一家公司，我们主要是与其他系统集成)。

对于最近的任何特定功能，我们必须对以下内容进行更改：

1. 数据工作在流行的基于云的客户关系管理(有一个单独的团队)
2. 在现场数据库工作，通常只有2或3的DBs为一个给定的功能3，两个单独的API服务应用程序-一个是在维护模式，直到所有的应用程序可以升级到新的API。两者都与上面的1和2集成在一起。
3. 连接到旧API的多个客户端
4. 连接到新API的多个客户端(一些连接到两个API)
5. 旧API调用新API是为了实现某些功能，因此在等待客户端更新时，我们只在一个地方集成了主要逻辑。
6. 我们有多个进程作为服务应用程序或应用服务器上的批处理应用程序运行。

*请注意，每个web客户端也有自己的后端服务器，在图中没有显示。

我用来攻击这个和创建用户故事的frame of reference类似于我在前一家公司的经历，主要是因为以下因素：

1. 团队规模(2-3)
2. 用户故事大小(8分)
3. 冲刺长度
4. 不同的客户端技术
5. 我觉得一个用户故事应该能够由一个人来处理，这样才能更容易地追踪完成。在某些情况下，工作可能是分开的，但在这一点上很可能处于水平水平(“您可以在他执行后端逻辑的同时执行数据库工作，而我将执行UI?")。

我认为我们最担心的是8分。在这方面，管理是灵活的，但不是很灵活。当故事情节是2-3个小时的时候就很难了。我提议的是，我们有一个“项目”的参考框架。例如，我相信在新的API中实现这个特性是8-13点的一个很好的成就。这可以包括数据库层等，所以它仍然是该生态系统中的一个垂直切片，但是我们正在水平地分割系统。

在此之后，每个客户端应用程序都可以是自己的故事，因为它们都有自己的客户机和服务器代码以及API集成。

我们(devs)通常尝试为主后端系统(业务逻辑)使用一个TFS功能，为客户端应用程序(后端系统的集成商)使用一个TFS功能。我们跟踪业务要求的大规模“功能”，当它们涉及广泛的应用程序时，将其作为计划或史诗，对于那些应用程序，我们可以为每个客户端应用程序提供一个功能。我们可以在一个像这样的sprint中处理2-3个特性，这样我们就可以更容易地跟踪到devs而不是试图有一个故事来实现这一点，它跨越了多个服务实现和web应用程序。

这两种方法都有优缺点吗?您是否有在大型应用程序/服务链中进行垂直切片的其他经验？

Answer 1

我发现，当您有如此多的依赖项时，它会“破坏敏捷”。基本上，您必须为依赖的系统更改编写规范，即使它只是“在您的大脑”，根据您对最终产品的预期需求。这些结果会被证明是错误的，或者是延迟的，或者是依赖于另一支球队，或者其他什么的，并且把你的冲刺搞砸了。

解决这一问题的一种方法是使您的受抚养人服务更加通用。因此，与service.getCustomers不同，例如，service.GetOrders将其扩展为service.queryAnythingDymanically。

而不是DataAccessLayer.RunStoredProc，而是改为DataAccessLayer.ExecuteEntityQuery等

这样就减少了“前端”更改需要升级到受抚养人服务的情况。

不过，也有不利的一面。服务越通用，测试就越难，性能可能下降，安全性更难验证。

另一种方法是使用微服务架构。这可以减少添加新功能的难度，因为与其更改现有的服务，您只需添加一个新的服务。

例如service1.getOrders -> service1.getOrders + service2.getNewStyleOrders

您仍然需要实现这些特性“一路向下”，但是您已经摆脱了一些向后兼容性和依赖性的担忧。

然而，采用这种风格的建筑并不像看起来那么容易。在您有一个明确的service1.getOrders端点要连接到的地方，您现在有了一个更异步的消息系统，监视丢失的消息，必须知道您的服务可以处理哪些类型，并确保整件事情被编排等等。