Re: Re: why is authorization in a separate layer from the model?
Caleb Cushing <[email protected]>
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <CAAHKNRF2M224BQRkJvhA0cAU1gNzQDPvP+tcKK1HUXsSC28zXw@mail.gmail.com> |
On Mon, Mar 11, 2013 at 2:02 AM, vvernon_shiftmethod <[email protected]> wrote: > Take a look at IDDD pages 75-79, and specifically at the refactored code on pages 78-79. It's not that it is absolutely wrong to in essence authorize the user in the model. Rather, it's that the authorization is done for free when obtaining the necessary Author instance from the CollaboratorService. > > Further, it's a matter that the Author is an essential part of the Ubiquitous Language, while your Session is not. If anything, rather than pass in Session (or worse yet, SecuritySession), pass in CollaboratorService instead, and use CollaboratorService to get the Author from the Forum's own Tenant and parameter String anAuthorId. well I understood how /author/ was an important concept. > In my sample code I show the Forum Application Service obtaining the Author via CollaboratorService. This is not wrong, because normally the API would serve as the natural client of the model. When using the Hexagonal (Ports and Adapters) architecture, requests from disparate user agent types would all be adapted to use a single API call. This is based on use case, not on user agent type. But you could pass in CollaboratorService to the Forum if you prefer. I think perhaps I simply do not yet understand what you're doing with CollaboratorService, and definitely need to try to understand the Hexagonal Architecture. I'm going to go back in and look at these pieces for sure tonight. My only thought though (and it doesn't fit real well in this context) is that what if author is more metadata? what if the person making the change is not the author but... some agent of the author, say the author's editor. In the case I was actually working on I was looking more at a ticket system with Ticket Owner where the Owner could be different from the Author and whom the ticket was AssignedTo. I was going to derive Author from the current User, and and Owner if the current user was a Customer. I was still need to check does the current (Security Session/Context/ w/e ) User/Role have access to create in this Queue and for this Owner. -- Caleb Cushing http://xenoterracide.com ------------------------------------