Not sure how it could work in your case. I think the main use case for SCRUM is applications development (web, desktop, mobile, whatever). In that context you have a mixed team of backend and frontend developers, or even better (in my opinion) a team of full stack developers. And so, tasks are not gatekeeped behind domain expertise and everyone in the team is able to pick whatever they want. Some developers usually have more experience with some parts of the codebase, but it's a good opportunity for the other developers to get comfortable with it too (which is, by the way, highly encouraged from the company's POV, in case if the only developer who knows that part of the codebase leaves the company).
I think maybe it has to do with having "product teams." There is no worry that we'd collapse if our EE or crypto experts left, we've got many more, just not on this team. And having one product per team is not typical except for specific "products" I happen to be involved in, for both practical (this software is written much differently than anything else for many reasons) and historical (this team at one point worked on a similar in some ways, completely different in others, product in the past, that was in a different business unit, with a different target platform and a different customer, and when that whole class of products stopped existing, they were moved over here).
