Design patterns for DDD

[nkosi23]

Hello!

I started to use SQLHydra but had to move away from it because I couldn't find a simple and elegant way to use Domain Driven Design. But today I realized that I could have tried to ask the question here.

The main item i struggled with was upserting Root Aggregates. A root aggregate is a top-level entity responsible for managing the internal consistency of multiple records. In practice, this means that reading and writing a root aggregate most of the time means reading and writing from and to multiple tables. The recommended practice therefore is to realize these operations atomically.

I struggled to come up with an elegant and scalable pattern to upsert a root aggregate, and to a lesser extent to load it from the DB. I felt that it was a bit hacky and that I was spending a lot of time writing boilerplate code. Between managing transactions manually and the verbose syntax to write joins, I found my implementation ugly and painful in terms of development experience.

Since the application I am developing is a large scale enterprise application, I need to ensure that things will be elegant and easy to develop even as complexity grows. But just writing read and upsert code for a single root aggregate was quite heavy on boilerplate code, while I got this stuff for free when I was using EF in C#.

I am very much interested in coming back to SQL instead of relying of ORMs, I see value in it. I was enjoying SQLHydra's API a lot before coming across this challenge. But I need to remain pragmatic and ensure that I do not multiply development time by 3 due to the need to write may more boilerplate code. Therefore, my specific question is: what would be the recommended pattern to serialize/deserialize a root aggregate using SQLHydra?

If there was a way to use stored procedure for every database operations I'd even be happy to do so, but i couldn't find a convenient pattern to pass an F# record to a store procedure (for upserts), and when it comes to reads, building a strongly-typed model without relying on magic strings felt painful as well.

But I suspect that it was probably because I was not familiar enough with the capabilities of SQL Hydra. This is the reason I'd appreciate if someone could illustrate how they'd approach this problem with basic pseudo-code samples.