Hi,

Regarding to "Explicit State Modeling" in Chapter 16, listing 16-19:

- Can Repository Identity Map break?: if the Entity is fetched from its Repository (and Identity Map hold a reference to it); when the state is changed, the client is aware and replace the current instance with the new one returned, but the Identity Map still holds the old instance. Resulting in two different Entities with the same ID, one just created, and another in the Identity Map from the Repository. Using the same Repository to save the new instance created could be weird due both has the same ID.

From my point of view, following the example from page 384, we could have a Repository for each class (InKitchenOnlineTakeawayOrder, InOvenOnlineTakeawayOrder, CookedOnlineTakeawayOrder, OutForDeliveryOnlineTakeawayOrder). Then, as each Repository has its own Identity Map, there is no conflict that a Repository has a reference to an instance ID and save another different instance with the same ID.

As a corollary, "Explicit State Modeling" has a separate Entity for each state, and also a separate Repository for each of those Entities.

Thoughts? Am I totally wrong?

Thanks in advance!
José Luis.

No, no, you're not wrong actually. And you have identified a problem with this pattern. Personally, I'm a fan of plain SQL (using Micro ORMs), so I avoid the complexities of ORM mappings that way.

However, as far as I can see you usually will need the same ID to be used consistently for each state of the entity. I haven't thought how an ORM-backed repository would look for such scenario.

If using SQL, you could have 1 repository, and 1 table, where the repository knows how to save each state, and the DB table has all of the possible columns, and maybe a flag indicating which state the Entity is currently in. That's how I would do it with raw SQL anyway.

If you find a better please let us know? Perhaps you could write a blog post? If you do, let me know and I'll retweet it.

In fact... I might knock up an example in Scala when I don't have 1 million other things on my Trello board

Thanks for your comment. Hope your enjoying the book. Any more questions, please keep them coming.

Thanks Nick.

Please follow this link https://medium.com/@martinezdelariva/explicit-state-modeling-f6e534c33508 where I tried to explain in detail the aspect to be considered when using Explicit State.

I take this opportunity to thank you for this enjoyable book!

Kind regards,
José Luis.

I think you've nailed it there. However.... I think it's not a massive crime for the Application Service to know which is the next state or which version of the Entity to load from the repository. It's debatable.

For example, this comment:

"✗ Client must know domain logic about transitions. That’s say, client knows that to close the door it must find an open door, then we are leaking domain logic in Application Service."

I think some people would say it's fine and others would disagree. It's that grey line between application/domain logic where different people have different perspectives. We tried to cover this in the book and explain there's no right answer, and it depends on your philosophy.

So some people would say it's ok for the application to know the next transition, because that's the business use case logic. Others would say it's definitely domain logic so use a domain service.

I really do think that either approach can work. I think the most important consideration is to keep it consistent with the rest of the code.

Thanks for writing that great post. I'm chuffed you enjoyed the book enough to want to do that