Longevity Goes Finally Tagless

Longevity - your persistence framework for Scala and NoSQL - has always sported a future-based API. But now in release 0.24, longevity has gone finally tagless, replacing the hardcoded references to scala.concurrent.Future with a generic effect F. We currently support three effects: Scala futures, the cats-effect IO monad, and an old-fashioned blocking API for the purists out there. We plan to support a variety of Task monads as effects in the near future, and you can always write your own effect as well.

For more information on longevity effects, see the user manual.

For examples on how longevity works with different effects, check out this demo code.

This release is exciting for me for many reasons. Perhaps most importantly, longevity now sports a truly functional API with support for IO monads. But the flexibility of the finally tagless approach is truly freeing. We can satisfy the purist functional programmers, and continue to support people who want to do reactive programming with futures, with a minimum of cognitive overhead. It's also exciting to me because it's a major step on my personal path to becoming a better functional programmer.

But the best part for me is just how beautiful the repository API has become. Just look at it. In a sense, this is how this API was always meant to be. Perfectly intuitive, fully typesafe, just the right level of abstraction without a hint of leaks. I couldn't imagine doing persistence in Scala any other way.

Advancing Enterprise DDD - Entities, Value Objects, and Identity

In the previous essay of the Advancing Enterprise DDD series, we saw how we might improve our Domain Driven Design model by making our entity classes immutable. Here, we continue to investigate immutable entities by seeing how this affects one of the core DDD building blocks: the value object.

Advancing Enterprise DDD - Migrating to Immutability

In the previous essay of the Advancing Enterprise DDD series, we saw difficulties emerge in maintaining intra-aggregate constraints. These difficulties arose due to the mutability of our entities, and the Java collections they use to maintain relationships between entities. We also saw that it would be difficult or impossible to use immutable alternatives within JPA. In this essay, we set aside the constraints of JPA for a moment, and imagine a world where entities are composed of immutable objects.

Advancing Enterprise DDD - Maintaining Intra-aggregate Constraints

In this essay of the Advancing Enterprise DDD series, we begin look to at immutable objects - a common point of contrast between functional and object-oriented programming approaches. In the last essay, we saw at how MongoDB would be a much better vehicle than RDB for persisting well-shaped DDD aggregates. In this essay, we continue to investigate at the way the tools we use affect our thinking and coding, as we witness the contortions we have to go through to make something as straightforward as an intra-aggregate constraint work in the face of mutability.