Examples using SQL and relational models. about goddd HOT 8 OPEN

I'm interested how you would implement a repository for the Cargo aggregate with the backing datastore being a RDBMS. Wouldn't you need to have a way to tell if child entities (that are likely their own tables) were updated or not, which would traversing the entire aggregate tree every time an update is required. Or would you just "upsert" every object - though this could become prohibitively expensive. Just curious how you think one would tackle these issues! Thanks!

from goddd.

I’m so very glad to hear that you’re finding it useful!

The Go community promotes evolving design, starting as simple as is required by you application rather than trying to fit every possible project into a certain structure. Rightfully so, the Go community has a healthy distaste for cargo culting. Though like you say, sometimes you just want to see some code to get a feeling of what it could look like. goddd is just that, an example of a non-trivial application that you can go to for inspiration, and use as a tool for discussing design.

Your domain model should not be depending on whether you’re using MongoDB or MySQL. That’s the very intention of the Repository. It lets you design your domain objects without having your arms tied by your choice of database. The Repository interface should make sense to the domain, rather than your database.

Typically the Store method in a repository should accept an aggregate. There’s some good information on designing aggregates here.

With that being said, I don't see any issues with separating Store into two methods:

type InvoiceRepository interface {
    Register(i Invoice)
    Update(i Invoice)
}

from goddd.

@marcusolsson, excellent! That clears that up quite nicely. If I could ask a follow-up, you seem to separate the processing of data into two layers service and repository. In my experience, the service layer is traditionally the realm of pure business logic and the repository layer is purely for persistence.

So, in the interface you've defined, should the persistence layer be expecting a fully-formed Invoice object that it dutifully passes along to the database? Things like assigning custom IDs and hashing passwords, are these best kept to the service layer? That's how I'm currently implementing things and its working quite well but I always like to check my reasoning against others with more experiencing in the area.

from goddd.

Right, if you by fully-formed mean that it has all data it needs to recreate the same invoice when you load it from storage. Here, Invoice is an example of an aggregate, which can be a group of one or more entities that is consistent (in terms of business rules) at any given time.

I would say that where you generate the IDs depends on their nature. For example, if you're using social security numbers to identify people, there are certain business rules that might apply. From Wikipedia:

The Social Security number is a nine-digit number in the format "AAA-GG-SSSS".

When registering new people, you're likely going to want to check that their SSN is valid. In this case, I would say that assigning IDs are part of the domain. On the other hand, if you just want a unique identifier for let's say a UserID, you could let your database generate one for you.

Personally, I prefer to generate them in the domain to avoid potential coupling to your database (even if it's just a UUID).

Thanks for sharing your thoughts!

from goddd.

@marcusolsson, awesome! Thanks for clearing that up and once again for the excellent project.

from goddd.

I was under the impression that one should NOT expose any database's instance id's used internally by the database (foreign keys and such) publicly.

from goddd.

@ghost: I've heard this bit of lore as well but never a compelling justification. Obviously you want to avoid exposing yourself to the risk of enumeration and predictable assignment so exposing incremental numerical IDs is a bad idea, but I see no reason not to use and expose UUID v4 identifiers.

from goddd.

can you give a mysql backend example? thank you very much

from goddd.