Re: Re: vaughn vernon - implementing domain-driven design - ch 2

I had a lengthy dicussion with Vernon and you are right, author basically represents a role. But I see all kinds of problems with, for example, author being use in separate bounded context (author of a discussion or user story). So as a real world implementation I'm not very pleased with the concept and probably would prefer moving the permission part into the actual bounded context.

Tom


On 2013-06-25 11:57, patrykzielu wrote:
>
> Hi Tom,
>
> I was digging too. And I found: com.saasovation.collaboration.application.ApplicationTest
>
> so I think you are right, there is no explicity diffrent between
> Discussion and Post Author.
>
> User with role Author can create Discussion in Forum and Post in Discussion.
> To create Forum you need to have role Creator.
>
> Question is do you need that kind of diffrence?. What your Domain Expert says about it. Ask him for use case creating Forum and Discussion. If it is explicity diffrent from what Domain Expert said than model it as diffrent classes(ForumAuthor, PostAuthor)
>
> --- In [email protected] <mailto:domaindrivendesign%40yahoogroups.com>, Tom Eugelink <tbee@...> wrote:
> >
> > Hi Patryk,
> >
> > Well, you're closing in to my problem. No, I did not know of that source code, that's very interesting. Only, I cannot find the implementation of CollaboratorService, it's an interface. Need to start digging there.
> >
> > About your suggestion: how does authorFrom know that it is creating a discussion? Author would also be an appropriate entity for a simple post inside a Discussion, so I expect createPost() to also use authorFrom method to convert a string into an Author. And it would be very acceptable that a User is allowed to post to on going discussions, but not to create new discussions. I feel the permission check being part of authorFrom to be questionable; the name suggests it merely searches if an author with the given ID exists.
> >
> > Tom
> >
> >
> >
> > On 2013-06-23 21:33, patrykzielu wrote:
> > >
> > > Hi Tom,
> > >
> > > First of all I don't know if you have sample project base on book?
> > > It is shared on git:
> > > https://github.com/VaughnVernon/IDDD_Samples
> > >
> > > What I understand is that in Collaboration Context Author need to have this permission to be created.
> > > There is context integration: CC(Collaboration Context) to AIC(AccessIdentity Context). When creating Forum only author has that kind of permission so when it is created by integration service CollaboratorService.authorFrom(Tenant aTenant, String anIdentity) there is checking if this User has this permission in AIC.
> > >
> > > I hope I understand your question, and I anser it correctly.
> > >
> > > --- In [email protected] <mailto:domaindrivendesign%40yahoogroups.com> <mailto:domaindrivendesign%40yahoogroups.com>, Tom Eugelink <tbee@> wrote:
> > > >
> > > >
> > > > Does anyone know if there is a forum to discuss Vaughn's book?
> > > >
> > > > I've just finished chapter 2 with a lingering question. I understand the example where User and Permission are not correct within the Collaboration Context, and that Author is more appropriate, moving User out to a separate Security Context. What I'm missing is how in the improved example the permission check is done. I can't find a call out to the Security Context checking if the User associated with the Author has permission to start a discussion. Should I assume that there is some kind of container checking this (just like the @Transactional is handled by a container)? I would be greatly against that, because that would bind a behavior aspect onto an (somewhat hidden) implementation; I'd rather have an explicit mention of the required permission behavior on Forum, or at least an
  explicit annotation @RequiresStartDiscussionPermission or something.
> > > >
> > > > Furthermore, the permission to start a discussion seems like a cross cutting problem; either the Collaboration Context knows about security, or the Security Context knows about forums and discussions.
> > > >
> > > > Thanks!
> > > >
> > > > Tom
> > > >
> > >
> > >
> >
>
>