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.
Best Answer
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.
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.