Updating properties with vertical slice architecture

Question

In Vertical Slice Architecture (VSA) you are supposed to have a class for pretty much every operation you can do (as I understand it). Some example, also mentioned in the referenced article, are:

• Get orders
• Approve invoice
• Cancel order

So if you want to approve an invoice, it is done via the ApproveInvoiceService class (or however you decided to name it).

But what about updating properties, which are typically controlled by the domain object? For example, if I have a Customer domain object, I could come up with quite a few properties which could potentially be changed/updated:

• First name
• Last name
• Phone number
• Address
• E-mail
• Gender (although more rare)
• etc.

The validation of all these would, presummably, lie on the domain object. The Customer class. Hence, if I made a service for changing each of these properties, they would essentially look the same:

1. Try update domain object
2. Persist changes to database

I haven't been able to find anything about this, in regards to VSA. Is it really the intention, to make so many similar services/handlers/whatever-we-call-them?

Answer 1

In Vertical Slice Architecture (VSA) you are supposed to have a class for pretty much every operation you can do (as I understand it)

Not literally every operation. Every cohesive group of operations. (And the article talks about slices, like "vertical layers", not just classes - a slice will often contain of more than just one class).

A good start for finding such operations are the use cases which the system supports, or operations which happen within a use case "as a whole". For example, any CRM system has an update operation for customer's core data. In this use case, a user may get a customer's mail that their adress has changed, and he/she will have to enter the data into the system. So there needs to be a functionality to search for specific customer, display it's current data and change certain properties, usually in one transaction. It does not make much sense to change the first name in one transaction, the last name in a second one, and the mobile phone number in a third.

So here is one vertical slice: finding / editing / updating a customer's personal data. Maybe the application (or part of the system) which implements this slice uses an ORM inside, maybe it uses repositories, maybe it uses raw SQL. The point of the VSA is that the next part of the system which uses the customer's main data (for example, the invoice creation) can be structured differently when looking at the horizontal layers.

Answer 2

Is it really the intention, to make so many similar services/handlers/whatever-we-call-them?

As far as I can tell, you only create so many similar services/whatever if you have so many similar user-facing features or API endpoints.

Thus, if changing both a Customer's phone number and address requires me to fill and submit 2 forms, then VSA recommends to have 2 services and possibly not even a shared Customer class.

On the other hand, if I can change all those Customer properties with a single form/request, then it can all be handled in a single slice.