Realm

Domain layer framework following Domain-driven/CQRS design principles.

Service layers

We follow the standard MVC design pattern of Rails but giving the model layer more structure and guidance regarding where to put your code. The model is split into domain layer (using our Realm library) and persistence layer (using ROM library). The individual components are explained in the following section.

Advanced components are shown in lighter color, those will be needed only later on as the service domain logic grows.

Model layer components

Each service has one domain module which consists of multiple aggregate modules. Aggregate is a cluster of domain objects that can be treated as a single unit. The only way for outer world to communicate with aggregate is by queries and commands. Query exposes aggregate's internal state and command changes it. The state of an aggregate is represented by tree of entities with one being the aggregate root and zero or more dependent entities with belongs_to relation to the root entity. The state of an aggregate (entity tree) is persisted and retrieved by repository. There is generally one repository per aggregate unless we split the read/write (query/command) persistence model for that particular domain. The repository uses relations to access the database tables. Each relation class represents one table.

Where to put my code as it grows?

TODO

Roadmap

• [ ] Support Ruby 3
• [ ] Make it work outside of Rails engines
• [ ] Support multiple persistence gateways in one runtime