Alejandro M. (1) [Avatar] Offline
Hello Debasish,

I'm carefully reading your book and i stopped in chapter 4, because i want to implement the concepts that i've seen so far (Repository, Reader, Lenses and Algebra). I started refactoring a CRUD that we have in our company and i have a question, but i'll show you first what i've done:

I have two tables to access and i want to do all the concrete repository implementation with Slick 3.1.1. The library enforces a mapping between my domain model and the database, but actually the real domain is only a subset of the table fields. The rest of them are "control fields" like 'last update date', 'last update user', 'creation date', 'creation user' and so on.
These fields are required but aren't part of the real domain, or at least the domain that the user is interested in.

My question is: what is the best approach to map between the concrete database implementation and my 'real' domain?

For example, this is the table:


And my domain is modelled like this:

case class Message(id: Long, name: String, subid: Long)

And i need it in that way, without all the database control fields because all of them aren't valuable for the user.

Do i have to create another aggregate for mapping between the database and the case-class and then extract only the fields that i need?

I apologize if this is discussed in further chapters.

Thank you.
Debasish Ghosh (111) [Avatar] Offline
I would not recommend making another aggregate. This is because those audit fields don;t have any domain representation and that's the reason they don't appear as part of your domain model. Typically the underlying db framework that you use can be tricked to accomplish such usecases. You can use the trick suggested by Stephan in this issue ...