Examples using SQL and relational models.

[dkushner]

First off, thanks so much for creating this repository. As a relative newcomer to Go, orienting myself in a landscape without established or strictly enforced best practices has been the toughest part of starting and this repository has been a godsend in terms of strategizing about project structure.

I've been having some trouble applying some of the principles here to my real-world services, however. Primarily, I have been having difficulty figuring out how to structure my models in a relational way, or rather where it is appropriate to load related models (repository, service, etc)? I'm using jmoiron/sqlx and also dealing with how to expand the repository interface to cover some more relational semantics that are not covered by the No-SQL example given in the repository.

For instance, only Store(obj *Object) is covered by the repository, but what if I'd like to handle the case of persisting a new object independently of persisting an existing object? In my case, I need to assign a custom ID to the new object and perhaps hash a user's password or something to that effect. Where would this best be handled and how?

[marcusolsson]

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)
}

[dkushner]

@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.

[marcusolsson]

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).

goddd/cargo/cargo.go

Lines 67 to 71 in e99d844

	// NextTrackingID generates a new tracking ID.
	// TODO: Move to infrastructure(?)
	func NextTrackingID() TrackingID {
	return TrackingID(strings.Split(strings.ToUpper(uuid.New()), "-")[0])
	}

Thanks for sharing your thoughts!

[dkushner]

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

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.

[dkushner]

@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.

[dmmulroy]

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!

[zpng]

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