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

DDD as she is done is mostly data-centric. Security is a concern, but
modeling it is not a top priority in the discussion since security in
practice for most software is rather anemic. I mainly focus on
collaborative data shares these days. That domain set needs security to
live in a first class model.

A similar problem can often be found in sagas because the modeling most
people do is object oriented and properties need to be introduced to
artificially talk about state transitions and context changes. Finally
hierarchical data is hard to represent in DDD because everything ends up
being an aggregate root of everything else all the way down the tree.

Long preamble, and I will focus just on security but I want to suggest here
that more patterned development of all these areas would benefit everyone.

In my mind, security is more about filtering what people can see than it is
about deciding what they can do. Things get done based on what can be seen
more than any other factor. In management we have a term for responsibility
allocation, RACI. Which stands for Responsible, Accountable, Consulted,
Informed. Google it for more. These four dimensions are security contexts
as well. Roles can be aggregated as collections of rights, with some
ability to configure those rights handed to administrators (they are
Responsible). I like to make a few fixed roles that make sense for
everyone, and then allow end users to make named roles based on job titles,
which become collections of the fixed roles. This means I make those fixed
roles smart, and consistent with licensing practice. We may have several
flavors of license for end users, and their available collection of roles
will reflect that. Roles are constituted as collections of individual
granular rights.

Regardless of the implementation, thinking about rights in these terms can
produce clearer answers that better reflect your applications use cases.

Structure(more than data, but start there), workflow and security are the
golden triangle of design. When you have all three together you are able to
walk through a problem and optimize it. I find domain experts unable to
clearly articulate security as a separate concern. They only understand it
in the context of a walk through of the workflows and dataflows. And then
when they do that, they will often have just one way of many possible ways
to organize the work in mind. Each command (thinking CQRSishly) has
associated data that read requests need to allow for that user to do the
job effectively. And they have to navigate to that work. Putting all those
factors together gives you a minimum graph of rights required to do a given
task and illustrates what each role depends on. Often simple paths only
have one solution, and complex ones rarely have more than a hand full. I
find it best to get the units of work down first, and then focus on
possible work flow variants, and finally look at roles. I like to make each
variant flow a set of rights so that administrators eventually trust the
naming and stick with sets of roles to implement a workflow. We ask them to
do so, but as I said, they are Responsible.

So my answer is principled but vague. Design it as flexibly as you need to
for the given situation. Clearly define how RACI works in your model.
Remembering that there are both positive and negative ways to do each of
the task types, and some outcomes are intentionally negative. That is ok.
Architects may love skateboarders and still consult them to find out if
their newest building design will NOT be their favorite place to skate.

Possibly consider an implementation like the one I have described as a
generic solution you can apply to any software you write. Also think
through your hierarchical data. Think through how to create abstract
hierarchies that work for you in workflows/sagas, security, and data
representation. Take DDD to the next level.



On Tue, Jun 25, 2013 at 4:57 AM, patrykzielu <[email protected]> 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], 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>, 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
> > > >
> > >
> > >
> >
>
>  
>