Finally, an ORM That Matches Modern Architectural Patterns!

We previously introduced Stalactite ORM, a disruptive tool in Java Persistence ecosystem. Indeed, mapping persistence through a DSL that leaves entity source class files untouched, as shown in the example below, has some positive and significant implications for software architecture.

EntityPersister<Country, Long> countryPersister = MappingEase.entityBuilder(Country.class, Long.class)
    .mapKey(Country::getId, IdentifierPolicy.afterInsert())
    .mapOneToOne(Country::getCapital, MappingEase.entityBuilder(City.class, Long.class)
        .mapKey(City::getId, IdentifierPolicy.afterInsert())
        .map(City::getName))

Participating In Domain Purity

To briefly highlight, Stalactite ORM provides a Domain Specific Language (DSL) for defining entity persistence mapping. Properties are targeted through Java method references, eliminating the need to modify your entity's Java file, as it would be necessary with annotations. This allows you to persist almost anything you want, as long as the targeted property has an accessor or a mutator. As a result, this ORM is an excellent choice for those who prioritize domain purity.

Moreover, even from a memory perspective, the domain remains pure: thanks to method reference usage, simple reflection, and a difference computation algorithm, Stalactite does not require bytecode enhancement to collect data for persistence or to set property values when rehydrating entities. As such, even the domain classes are left untouched and free from any ORM-specific bytecode.

Embracing Single Responsibility Design and Separation of Concerns

A positive side effect of such a non-intrusive approach is that it does not dictate how your entities must be persisted when delivering your business domain. Often, to facilitate integration, domain entities are persisted by following the annotations given by the business domain, which may not suit the database schema. Stalactite ORM assists by allowing the repository layer to determine how entities are stored and queried, selecting the properties it needs, or rearranging table mapping. 

This can be very helpful in a transitional path to clean up a code base, either by providing a better business domain and keeping a legacy database schema, or by cleaning up a database schema and keeping a legacy domain. Obviously, this can also be done with JPA, but it requires extra effort, including redefining a complete set of entities, and implementing a mapper system. This process is very time-consuming, costly, and introduces unnecessary boilerplate code. Stalactite ORM will delay this need and, as we see, fully leave persistence responsibility to the repository layer.

Matching Hexagonal Architecture

Thanks to this non-intrusive approach, the business domain becomes really portable and reusable. The business code can also be shared with other projects in your company, without imposing the persistence layer dependency, making it lightweight and business-logic-centric.

Moreover, promoting aggregate persistence mapping through a fluent DSL makes it easier to visualize and manage the complexity of entity relationships. This aligns very well with Hexagonal Architecture’s emphasis on clear and maintainable code. Also, by fetching entities eagerly, it produces a clear and predictable entity graph, creating a well-defined context without side effects when crossing boundaries caused by lazy loading.

Conclusion

Software architectures have greatly evolved during the last decade, as they attempt to master growing complexities while keeping maintenance affordable. However, the persistence layer remains a challenge to maintain. In this context, Stalactite ORM contributes to the effort by adhering to modern architectural patterns. Version 3 is in active development and will bring Spring Data integration to make the transition from your actual ORM as seamless as possible, then, the persistence mapping definition will be back to where it should have always been.