Best practice refactor n-tier into vertical slices architecture

Question

What work path do there exist to identify reasonable vertical slices of a classic n-tier platform code base and infrastructure (enterprise size)? Regardles of refactor or a new solution I think there will be the same approach (more or less?) So i'm primary interested in steps and definitioning of modules, functions, then "test" them into a function-unit or if it's appproved as a vertical.

To extend my thoughs..
I understand that a vertical should be a actor, a kind of business value. But is a communication system a actor, or a functional unit in a vertical slice? Probably yes And no (depends on enterprise), but how to decide? Is shipment a part of Order, or are both Order and Shipment different verticals?

What should a vertical slice consist of, to be a true vertical? In terms of Levels of functions, like "an own data store, an own client configuration tool, an own business intelligence calculation" and so on. Btw: It's a requirement that the verticals should be deployed and operatable independently of each other.

Maybe there is a kind of "yes/no" schema to use? "Is this X used for Y?" Yes - then it's a vertical. "Is this X used with Z?" - Yes, then it's anti-pattern for vertical. "Is X depend on the funtion YY?" If yes, then..

And so on. Links to success stories when define verticals is also of interest.

Answer 1

Tackling a significant refactor requires you to have a solid understanding as to why you're performing that refactor.

I'll rule out the hobby level justifications such as "make the code more pure" or "improve stylistic expression" or similar. Those aren't bad justifications, but a commercial project will almost never see or use that level of justification for a major undertaking.

In contrast, commercial level refactoring justification always involves pain.

• "Maintenance has become impossible."
• "The code base can't be extended."
• "Code changes generate obscure errors in unanticipated areas of the code."

Pain justifies the expense and risk involved. And pain leads you to your answer. You refactor in order to minimize future pain. Refactor in order to encapsulate the change.

You mentioned a couple of aspects such as communication systems, orders, and shipments. And you correctly called out that there isn't a one-size-fits-all approach to identify what belongs where. Every system is different based upon its domain and business need.

For your system, identify what is changing. Push that into its own vertical that conforms to a contract or an API with the rest of the system. Whenever that section changes, you can verify it still meets its contract and control the amount of damage from the code change.

Answer 2

The correct way may not be strictly horizontal or vertical, but wavelet:

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

• X-axis: functional units of an enterprise (Order, shipment, etc)
• Y-axis: the layers of software architecture (database, transactions, message queues, services, web-services, front-end)

The key is to build the lower-level layers of software in a highly-reusable way, and easy for the higher-level users, so that the developers of the higher layers do not need to spend too much time redoing what the lower-levels ought to be doing.

The advantage of the reusable lower-levels can be extended beyond software programming - configurations, virtual-machine images, software licenses, and even hardware specifications (or even standardized server machines) can all be designed with reusability (by multiple business units) in mind.

The higher layer may need to talk to multiple functional units to get things done.

Consider the issue of customer support in your example.

• If there is a problem in the Order system, the customer needs to be contacted.
• If there is a problem with Shipping, the customer also needs to be contacted.

The blog post http://simpleprogrammer.com/2011/11/21/understanding-the-vertical-slice/ suggested by @user61852 talks about writing new software. When taking the vertical slice approach, one tries to satisfy a small facet of functionality requested by a single functional unit, by implementing the smallest amount of software.

• Example: If shipping needs to talk to the customer, they will only be given an extension number to the customer representative department and a customer ID. Someone in the shipping department needs to do this manually.
• In the future, it may be integrated with Skype, but that's the long future.

The blog post implies the use of a lot of mock-ups, throw-away UIs, and prop-ups (imperfect way of meeting part of functional requirements) while a more endurable implementation is scheduled later in the project.

The blog post does not talk about refactoring an existing enterprise software system.

As @GlenH7 implies, if it's working, don't make risky changes to it.