Edward Yakop wrote:
The simple rule is that the domain model cannot use any services, and
therefore is not able to call the SMS service. The only thing it can do
is build up the state of the domain model.
Ok.. I can't think a single use case that breaks this rule atm.
Does this mean we're going to enforce this?
Any entity mixin must not have @Service declaration?
No, we don't enforce it. But it makes it harder to see any usecase for
Entities to use Services, that's for sure.
But this might be entirely wrong. It might be that command execution is
something entirely separate from the entities themselves, i.e. should be in
services or similar.
Another thing that I noticed
If we look at DDD sample, where a routing service doesn't belong to any entity.
How should we model this "routing" command?
Not sure.
If we have a simple rule entity must not use any service.
Each application will be isolated, even if there's a integration between
application A and B. This integration aspect is irrelevant during migration.
Yup.
one additional question: How do we migrate eventV1 -> eventV2?
That way in v1 -> v2 -> v3
We don't have to redo v1 -> v2 migration.
Hence, eventually we can take these old migration code out from the code.
Note: In this case event is not an audit record.
One way is to say that you don't migrate events at all. I.e. if you want
to "change" you mark current event method as deprecated, and create the
new one as you want it to be. We might allow some forward-compatible
changes though to make this easier. Not sure.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
