This project provides patterns from the world of Domain Driven Design.

This trait defines characteristics of a repository, which is a collection like abstraction over database access. This trait is modeled very closely to function signatures used by the standard libraries HashMap because that is the closest analog. There are some key differences though, largely around ownership. The standard library wants to own it's values, but in the case of a collection "like" abstraction over database access, it doesn't make sense for a repository to own it's data. The database owns the data and that data is passed to the repository which constructs an entity and returns that entity to the caller.

Due to the nature of the abstraction, it makes more sense for the Repository to take in references (because that's all it needs to persist the data to an underlying storage system) and return owned values.

Unlike the standard libraries HashMap api, the insert does not update the value at the key, if the key already exists. This is to prevent misuse of the repository. The logic is flipped from HashMap's insert method. If the key already exists, then None is returned. If the key does not exist, then the entity itself is returned. This is useful for cases in which we want to update an entity with computed data from a database and return that to the caller.

The other way in which this differs from the API for the standard libraries HashMap is that all methods return a Result. This is due to the fact that we might have a failure to communicate with the underlying storage mechanism, or a concurrency related error that needs to be communicated back to the caller. The success case very closely matches what you get from the standard library HashMap while the failure case communicates an issue with the underlying storage mechanism.

The entity trait simply defines that an entity must have some sort of persistent identity. This is established with a single function signature that ensures any Entity must have an id() method that returns a globally unique id of some kind.

The ValueObject trait defines characteristics of a value object, which is an object that holds some immutable value, and validates incoming data to make sure it conforms to certain requirements. An example would be if you have an Email struct. At all times that struct should only hold valid email addresses. If Email implements ValueObject trait, then the implementor will be required to write a try_from implementation, which should in turn call their implementation of validate and essentially return an error if validation fails, or create a value object upon success. Some rules for value objects are:

1. Value objects are immutable.
2. Value objects should validate data that is used to construct them (the "value" they hold after successful validation).
3. Value objects do not have globally unique identity.

License: MIT