将n层重构为垂直切片体系结构的最佳实践

Question

有什么工作路径，以确定合理的垂直切片的经典n层平台代码库和基础设施(企业规模)？考虑到重构或新的解决方案，我认为会有相同的方法(或多或少？)因此，我主要感兴趣的是模块、函数的步骤和定义，然后将它们“测试”成一个函数单元，或者如果它被追加为垂直的。

扩展我的思想..。

我明白一个垂直应该是一个演员，一种商业价值。但是，通信系统是一个参与者，还是垂直切片中的一个功能单元？可能是和不是(取决于企业)，但如何决定呢？装运是订单的一部分，还是订单和装运都是垂直的？

垂直切片应该由什么组成，才是真正的垂直？在功能级别方面，比如“自己的数据存储、自己的客户端配置工具、自己的商业智能计算”等等。顺便说一句:这是一个要求垂直应该是部署和操作独立于彼此。

也许有一种“是/否”模式可以使用？“这个X是用来做Y的吗？”是的-那是垂直的。“这个X和Z一起用吗？”-是的，它是垂直的反图案。“X依赖于YY的功能吗？”如果是，那..。

诸若此类。当定义垂直点时，链接到成功的故事也是有意义的。

Answer 1

处理一个重要的重构需要您对执行重构的原因有一个坚实的理解。

我将排除爱好层次的理由，如“使代码更纯净”或“改进文体表达”或类似的理由。这些并不是很好的理由，但一个商业项目几乎永远不会看到或使用这种程度的理由为一项重大的事业。

相反，商业层面的重构总是会带来痛苦。

• “维修变得不可能了。”
• “代码库不能扩展。”
• “代码更改会在代码中未预料到的区域产生模糊错误。”

痛苦证明所涉及的费用和风险是合理的。痛苦会让你找到答案。你重构是为了减少未来的痛苦。重构以封装更改。

您提到了几个方面，例如通信系统、订单和发货。你正确地指出，没有一种一刀切的方法来确定什么是属于哪里的。每个系统都因其领域和业务需要而不同。

对于您的系统，请确定正在更改的内容。将其推入符合合同或API的垂直方向，并与系统的其他部分保持一致。每当该部分发生更改时，您都可以验证它是否符合其约定，并控制代码更改造成的损坏量。

Answer 2

正确的方法可能不是严格的水平或垂直的，而是小波：

http://www.mathworks.com/help/wavelet/gs/ch01_intro42.gif

• X轴:企业的功能单位(订单、装运等)
• Y轴:软件体系结构的层次(数据库、事务、消息队列、服务、web服务、前端)。

关键是要以一种高可重用的方式构建软件的底层，这样更高层的开发人员就不需要花费太多的时间来重做低级用户应该做的事情。

可重用低级别的优势可以扩展到软件编程配置、虚拟机映像、软件许可，甚至硬件规范(甚至标准化服务器机器)都可以在设计时考虑到可重用性(由多个业务单元进行)。

较高层可能需要与多个功能单元交谈，以完成任务。

考虑一下您的示例中的客户支持问题。

• 如果订单系统出现问题，则需要与客户联系。
• 如果托运有问题，也需要与客户联系。

@ post 61852推荐的博客文章http://simpleprogrammer.com/2011/11/21/understanding-the-vertical-slice/谈到了编写新软件的问题。当采用垂直切片方法时，人们试图通过实现最小数量的软件来满足单个功能单元所要求的功能的一个小方面。

• 例如:如果航运需要与客户沟通，他们将只获得客户代表部门的分机号码和客户ID。运输部门的人员需要手动进行此操作。
• 在未来，它可能与Skype集成，但这是一个很长的未来。

这篇博文意味着使用大量的模拟、丢弃UI和支持(不完美的方式来满足部分功能需求)，而更持久的实现则安排在项目的后面。

博客文章没有提到重构现有的企业软件系统。

正如@GlenH7所暗示的那样，如果它有效，就不要对其进行危险的更改。