Storing information about who did what

[Alexander M]

Hi all,

Reading IDDD kept me wondering when/if you model the "users" doing things. An example from the book is committing a backlog item to a sprint. This is modeled in the following way: backlogItem.commitTo(sprint).

In this example there is no information about who committed the backlog item to the sprint. I'm assuming this might be something that an application wants to show. Where would you store this information? Should the model be altered if you think this information is important? For example: teamMember.commitBacklogItemToSprint(backlogItem, sprint)?

Maybe this isn't the best example, but in general I'm wondering what approaches are of handling this.

Kind regards,

Alexander

[Markus Gärtner]

Let me be a bit nitpicky here: The team commits a backlog item to the Sprint.

But seriously, you might derive the actual user from the LoginCredentials globally or make them explicit in the interface. Iirc when you read further that issue is dealt with in the book.

Best Markus

--

Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

Agile Team Academy, September, Amsterdam http://www.agileteamacademy.com/

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alexander M]

On Sun, Apr 28, 2013 at 2:59 PM, Markus Gärtner <mgae...@gmail.com> wrote:

Let me be a bit nitpicky here: The team commits a backlog item to the Sprint.

Agreed. The example doesn't mention any of them, that's why it kept me wondering.

But seriously, you might derive the actual user from the LoginCredentials globally or make them explicit in the interface. Iirc when you read further that issue is dealt with in the book.

Ok, and then the reference to the user is stored where? In the event? In the metadata of the event? I read the whole book, but maybe I'll have look up these bits again.

Best Markus

--

Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

Agile Team Academy, September, Amsterdam http://www.agileteamacademy.com/

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

On 28.04.2013, at 13:10, Alexander M <iam....@gmail.com> wrote:

Hi all,

Reading IDDD kept me wondering when/if you model the "users" doing things. An example from the book is committing a backlog item to a sprint. This is modeled in the following way: backlogItem.commitTo(sprint).

In this example there is no information about who committed the backlog item to the sprint. I'm assuming this might be something that an application wants to show. Where would you store this information? Should the model be altered if you think this information is important? For example: teamMember.commitBacklogItemToSprint(backlogItem, sprint)?

Maybe this isn't the best example, but in general I'm wondering what approaches are of handling this.

Kind regards,

Alexander

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/8NttjjaL1CM/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Marijn Huizendveld]

Perhaps it would be more useful to select an example from your own domain.

[Dennis Traub]

User, session, time, version and other metadata is usually stored as part of an envelope (metadata), not as part of the event itself (payload).

[Alexander M]

For now I only have a toy project where I'm trying out DDD/CQRS, so it's not very realistic. I currently have a domain where "Issues" are managed.

An issue can be:

- reported, then it will be unconfirmed

- unconfirmed issues, can be confirmed or closed

- confirmed issues can be resolved

- resolved issues can be closed

- closed issues can be reopened

In the application I'd like to show a log of who did what. So who reported the issue, who confirmed it, etc. I'm now wondering if this should be in the domain, and if yes, how it should be modeled. From what I've read up until now I have the feeling you don't model the "user" doing things explicitly everywhere. As in: 

- "Reporter.reportIssue(id, description)" vs "Issue::report(id, description)" vs "Issue::report(Reporter, id, description)"

- "Developer.confirm(Issue)" vs "Issue.confirm()" vs "Issue.confirm(Developer)"

In both cases the 3rd option look a bit weird (an issue confirming a developer?). From the material I've read so far (blogs, presentations, iddd book), the second option seems to be used a lot, but how is the user handled in that case?

Thank you all for the replies thus far!

[Philip Jander]

>
> In the application I'd like to show a log of who did what. So who
> reported the issue, who confirmed it, etc. I'm now wondering if this
> should be in the domain, and if yes, how it should be modeled. From
> what I've read up until now I have the feeling you don't model the
> "user" doing things explicitly everywhere. As in:
> - "Reporter.reportIssue(id, description)" vs "Issue::report(id,
> description)" vs "Issue::report(Reporter, id, description)"
> - "Developer.confirm(Issue)" vs "Issue.confirm()" vs
> "Issue.confirm(Developer)"
>
> In both cases the 3rd option look a bit weird (an issue confirming a
> developer?). From the material I've read so far (blogs, presentations,
> iddd book), the second option seems to be used a lot, but how is the
> user handled in that case?
>
>

it boils down to the question whether your user/developer is also a user
of the system. If so, the record of "who did what" is an infrastructure
concern. For storage with event sourcing, see what Dennis wrote above.
For reporting, you can create a normal readmodel which feeds from all
events (and takes its information from the envelope meta data in
addition to the events themselves). You still need to model your user
administration/security domain, but that is a different context. Some
use DDD for this, some use external services, some use other kinds of
implementation, it all depends ;)

If you "Developer" is *not* a user of the system, then you would
actually explicitly model the Developer as you suggested. But that would
imply that a third party (system user) registers what the actual
"developers" do. I suppose this is not your scenario.

Cheers
Phil