1
votes

I am working on a legacy project and trying to introduce CQRS in some places where it's appropriate. In order to integrate with all of the legacy which is relational I would like to project my aggregate (or part of it) into a table in the relational database.

I would also like the aggregate ID to be the auto-incremented value on that projected table. I know this seems like going against the grain since it's mixing the read model with the write model. However I don't want to pollute the legacy schema with foreign key GUUIDs.

Would this be a complete no-no, and if so what would you suggest?

Edit: Maybe I could just store the GUUID in the projected table, that way when the events get projected I can identify the row to update, but then still have an auto incremented column for joining on?

1
I think you have answered your own question. Allowing the database (which is a piece of infrastructure) to determine identity within your domain is a violation of CQRS (because you have to perform both a read AND a write to retrieve a new identity) and it binds the scalability of your application to your database. Make it easy on yourself and use GUIDs.Matt
Thanks, yeah I think I rubber duck debugged and thought of the answer after writing the question down!rgvcorley

1 Answers

2
votes

There is nothing wrong with using an id created by the infrastructure layer for your entities. This pattern is commonly used in Vaughn Vernon's 'Implementing DDD' book:

  1. Get the next available ID from the repository.
  2. Create an entity.
  3. Save the entity in the repository.

Your problem is that you want to use an id created in another Bounded Context. That is a huge and complete no-no, not the fact that the id is created by the Infrastructure Layer.

You should create the id in your Bounded Context and use it to reference the aggregate from other Contexts (just as you wrote when you edited your question).