Application Core Domain Model Design with SwiftletModel
#SwiftletModel
Another interesting SwiftletModel use case is designing the application core domain model. Something that Martin Fowler called "Rich Domain Model" in his classic "Patterns of Enterprise Application Architecture" book.
Why is it a good fit?
Typically, when we think of an application domain entities, it's common to implement them as reference types, because
- They naturally have reference type semantics
- In most cases, we deal with some sort of relational data model graph, which feels easier to express with reference-type objects.
SwiftletModel flips this trade-off. It gives you a normalisation, denormalisation, and resolution tool to build the relational model graph with plain structs and maintain data consistency in a declarative way.
This approach brings a large number of benefits.
We basically get the best of two worlds:
- identity semantics of reference types
- value type guarantees of plain structs: immutability, sendability, codability, performance, etc.
SwiftletModel entities don’t get their capabilities from a base class, unlike typical ActiveRecord-like ORMs. That avoids a whole class of issues caused by hidden mutable state and unexpected side effects.
Another important difference from traditional ORMs is that it's not built on top of any database or persistence layer with its specifics. As a result, persistence layer details never leak into the domain model.
Instead, SwiftletModel gives you many of the tools you’d normally expect from a database, but in memory: lookups, normalization, bi-directional relations, sorting, filtering, indexes, full-text index, soft delete, and model metadata (last modified, etc).
Why does this matter?
Because your thin client app doesn’t need a full database (most likely). Most likely, your app needs a reliable way to manage an object graph gracefully, cleanly, predictably and without surprising side effects.
Comments