Tracking changes when not using an ORM

[Jeff]

So I know this can be frowned upon by some camps, but different discussion for a different day.

My background is in Microsoft and therefore when doing DDD, i was able to use Entity Framework to track all changes for me and know what to submit to the database.

I am now using open source and no ORM.  How do we track changes in the domain to persist back to the data store?  I'm guessing that is where domain events come into place?  Raise these back to the application layer which then uses a repo to persist?  I understand that this is also where domains would be then pushed out to other subscribers. I'm really just getting clarification on my perception of dealing with change tracking against an AR, which i used to handle with Entity Framework change tracking.

Thanks

[Hendry Luk]

Not sure how this relates to this group but...

Why not using ORM then?

Well you don't literally need ORM (or rdbms), but just a similar data persistence framework. Not sure what platform you're on now, but in java for instance, if you're using spring-data (or the JavaEE equivalent), you can back it with virtually any persistence technology (ORM/JPA, neo4j, cassandra, mongodb, etc), and they're all designed specifically to do what you want: repository implementation, change-tracking, unit-of-work, and other stuff.

But since you're in this group, an popular alternative to entity persistence is by event-sourcing, i.e. you don't persist your entities, only the events that are raised. To reconstitute the entities, you replay those events.

--
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeff]

we are using go (golang) and the tools available are limited at this point.

[Michael Clark]

In my opinion change tracking is really a concern of the persistence layer, not of your domain model or even your application services.  I'd recommend keeping that concern within your repository layer, and if the tooling isn't available for your current persistence technology (like EF for RDBMS) then you can choose to implement your own (and also push it to Github to become an OSS rockstar :)).  

Alternatively, you might seriously consider using Event Sourcing as your persistence mechanism like Hendry suggested.  This would not only give you change tracking for a particular session, but it would give you change tracking over the entire life of your ARs.

[Eve Ragins]

The way I am currently handling this is to just repersist the whole aggregate whether it needs it or not. The particular one that pushed me away from using an ORM will never become large, but it is spread across many tables, and how I work with the data is different from how I want to persist it. (My read/write store is the same source and I am not using event sourcing.)

I justify the inefficiency to myself by the idea that the write side will be used significantly less than the read side. I figure if performance becomes an issue then I can worry about it at a later date.

Not saying this is the best way, but it is an option.

[Kijana Woodard]

How are you handling concurrency issues?

---

From: Eve Ragins
Sent: ‎1/‎29/‎2016 9:23 AM
To: DDD/CQRS
Subject: [DDD/CQRS] Tracking changes when not using an ORM

The way I am currently handling this is to just repersist the whole aggregate whether it needs it or not. The particular one that pushed me away from using an ORM will never become large, but it is spread across many tables, and how I work with the data is different from how I want to persist it. (My read/write store is the same source and I am not using event sourcing.)

I justify the inefficiency to myself by the idea that the write side will be used significantly less than the read side. I figure if performance becomes an issue then I can worry about it at a later date.

Not saying this is the best way, but it is an option.