Hello, and happy new year 🎆 I am working as an architect and developer, and I am having a discussion with our developers, regarding the schema model, I am arguing for the schema model is leaning against the domain model, but the developers want to make the schema as simple as possible, where everything is tied together with a generic group, and the have some specific relations, and even connecting the definitions a different way, compared to the domain model. I think this approach is wrong. I want to define the schema model, so it looks like the domain model, so it is easier to understand and the security is declared in as many non generic definitions as possible. My question is, is there a wright or wrong way, to define and use the schema? What is the recomendations?

Your intuition is right, that's what we've seen done in the wild too: as close as possible to the business domain. I understand the desire from the developers to have a schema that rarely changes because it's as business domain agnostic as possible, but that'd pushes the responsibility of doing the right thing to the application vs the database enforcing a specific schema and type system. When it comes to authorization, you want it dumb easy to reason about and hard to make mistakes. I'd also be surprised they can get away with that model for too long as business needs evolve.

Hi, Thank you for your quick response. I am a bit unsure, what is the correct, from you answer. We as architects want the schema model to be close to the domain model, so the definitions and relations are as descriptive as possible, so we can test and trace everything easily. The developers just want a generic group definition, which can be used for everything. This way the final auth model is build in code instead of declarative. What is the "correct" way? The architect or the developer way 🙂 Another question. What happens if we add or remove a permission, on a definition. Will SpiceDb rebuild the actual permission in the database?

I don't think there is a wrong way, and I certainly can't judge without context about your domain and organizational structures. There are patterns that can make your life harder down the line. - A generic model means more data may have to be loaded to answer authorization requests, because less but wider relations have to be traversed. - It may make your life harder if you need to evolve your schema, e.g. refactoring relations. Refactor would a larger blast radious. - It pushes correctness with respect to the domain model to the application, which requires a high degree of discipline, which is challenging as engineering organizations grow. - It will spread the implementation details to other parts of the application that want to be onboarded onto the authorization platform and interoperate with the existing schema. Perhaps the question to ask is what is so compelling to the engineering team about the generic group definition they feel strongly about it. What makes it easier for them to adopt? Removing permission on a definition has no impact. Removing relations, on the other hand, can only be performed if the relation has been "drained", meaning there are no relationships attached. This is what I mean with harder to evolve the schema: you may find yourself doing 4-phase migrations that depending on the data size can take some time and coordination to execute.

Thanks 🙂

anytime