Domain model defining relationships

Question

Assuming everyone has the rights to do the CRUD operations (everyone is an admin type user). I have displayed CRUD operations the user can perform in the Domain diagram however, it's become quite messy. I am curious if it's acceptable to do the alternative approach shown in the images below instead since the multiplicative relationships remain the same for each action (create,edit,delete)

Seperated CRUD

Alternative approach? (create, edit, delete)

Answer 1

In short

If it becomes messy, it probably lacks of separation of concerns, or represents associations that are not really needed.

More explanations

Are the associations needed?

An association between User and Xxx implies a semantic relationship between the two classes. This means that instances of the classes are linked and not just for the time of an operations. So x would be able to find the User(s) that updated it, and u would know the Xxx instances that it updated. This kind of association can make sense if you want some audit trails, but this seems not to be your purpose here.

In other words, the fact that a User may perform some operations that CRUD instances of Xxx is not sufficient for justifying an association.

If they are needed, do they represent what you think?

Now it appears that your associations are can ..., i.e. some kind of authorisation scheme. Your diagram tells that each user would need to know in advance all the Xxx that it could update. This is a heavy burden. It would also imply that a user needs to know all the Xxx it can create; before they are even created? This looks somewhat inconsistent.

Modeling an authorisation scheme

If you'd wand to design an authorisation system, you'd probably not link users directly to the object, but use some intermediary mechanisms:

• To express that a user can create new projects, you'd probably have some authorisation object that tells the caracteristics of projects that can be created.
• To express that a user can edit, update, delete projcts, you could have a direct association like you envisaged, if some admin would maintain such authorisations.
• But probably you would have some authorisation object that would tell what a user can do (e.g. a user "role"/"profile") and what category of projects.
• Equally probable is that there are some rules that govern CRUD authorisations (e.g. a user having the role "edit" can edit the project he/she is assigned to, but not the others). Making use of such rules instead of explicitly designing (redundant) authorisations could then save you a lot of unnecessary extra associations (and extra constraints to keep the authorisations consistent with the rules).

Separation of concerns

And to keep things continue to be messy, you should consider:

• having a separate diagram in your model for the authorisation concept
• use some common CRUD interface: the users would then be associated with the CRUD interface without having to replicate everything for every possible class.

Answer 2

The main issue with both of your class models is a confusion between the type/instance levels. Your "can create/edit/delete" authorization relationships do not hold between a specific user and a specific object (an instance of Company, Project or Ticket), but rather between a specific user and a sepcific object type (Company, Project or Ticket), so it's not an ordinary association between two ordinary object types.

If you want to describe/define such authorization relationships with a class model, you would need to define a meta-class like ObjectType and express that your object types (Company, Project or Ticket) are instances of it.