In an anti-corruption layer, is it Ok to translate into an Entity instead of a Value Object?

[Michael Azerhad]

Hi,

The IDDD book (Vaughn Vernon) deals with the translating of a user's role from the IdentityAndAccessContext to the Collaboration Bounded Context.
This is on page 460. 

Basically, it translates user's role to a Value Object:  Moderator / Author etc. 
Advantage is to NOT be impacted by the lifecycle of an Entity and easily reason about.

Now I wonder about this kind of scenario where you need the lifecycle of the corresponding Entity: 

I want to update the biography as an Author.
Typically, this notion isn't tied with a User Entity from the IdentityAndAccessContext and is particular to the Collaboration BoundedContext.

So this use case's workflow would be: 

1. Call the anti-corruption layer service to deal with authentication/authorization from the IdentityAndAccessContext and returns an Author as a Value Object if matches. 
2. From this Value Object's id, retrieve the Author as Entity from the AuthorRepository in the Collaboration Bounded Context. 
3. Call the method updateBiography on this Author Entity.

Is it a good practice? 

What would you advise? 

Thanks a lot. 

 

[Veranildo Veras]

In my opinion: Will the process of updating an author's biography also update the author's data? If the answer is no, you will have the author as an object of value also in this context

[Michael Azerhad]

Yes, we could imagine the biography field as a field of the Author Entity. 
It's internal to Author entity. 

In the global case, I would have an Author as a value object resulting of the translation of the User's role AND the Author entity belonging to the Collaboration Context.
Wouldn't it be confusing?

[Veranildo Veras]

Yes it is confusing, you add or remove author to a biography, I see no reason to update the author's data.

Em domingo, 6 de agosto de 2017 06:24:10 UTC-3, Michael Azerhad escreveu:

[Michael Azerhad]

Indeed :) 

So you wouldn't have an Author Entity at all? Only the Value Object version? 
Would you imagine a use case where an Author Entity is worth it?

Thanks :)

[Michael Azerhad]

For instance, let's imagine that the Author has a profilePicture field that User on the I&A context does not have. 

With an Author as an Entity in the Collaboration Context, we could add and persist the Author with this profile picture. 
Advantage : Shared between all Author instances over the time.

With a Value Object, if you started creating a Discussion with an author having the "1.jpg" profile picture url, you don't have mean to update it afterwards, when "2.jpg" replaces it.
Indeed, each instance of this Value Object regarding the same Author would be unique per Discussion, no shared data.

Or the solution would be to create a ProfilePicture Entity, linked to a Value Object Author?

[Veranildo Veras]

I imagine that in an context there is an author represented by an object of value, in other contexts there may be an author of an entity

[Dominik Przybysz]

Hi,

I would propose not naming the Author as user from the IdentityAndAccessContext and your entity in the CollaborationContext. It is a bit confusing.

Maybe you can do something like this:

```

AuthorUser authorUser = userRepository.getAuthor(...)

```

and your entity could be similar to.

```

class Author extends Entity {

    AuthorId authorId // get from authorUser

    Bibligrahy bibliograpthy

    // ...

}

```

--
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+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

--

Pozdrawiam / Regards,

Dominik Przybysz

[Dominik Przybysz]

Do you want to use the same Author entity for query model and display it on UI? I do not think it is a good option.

The profile picture is connected with the IdentityAndAccessContext and should be changed in this context.

--
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+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Michael Azerhad]

Hum..I don't think that this kind of profilPicture should take place in the I&A Context.
It's not tied with permissions or authentication IMHO.

[Dominik Przybysz]

It depends on your domain, but it looks like something very connected with the User Identity. Maybe there should be more contexts? Maybe there is a place for more contexts? IdentityAndAccessContext, CollaborationContext and ProfileContext?

What is more, if you want to have a profile picture, then probably not only Author entity should have it.

2017-08-06 20:59 GMT+02:00 Michael Azerhad <michael...@gmail.com>:

Hum..I don't think that this kind of profilPicture should take place in the I&A Context.
It's not tied with permissions or authentication IMHO.

--
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+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Michael Azerhad]

Indeed, a third bounded context would be overkill in this case.
I agree with your point of view.