Advancing Enterprise DDD - Rethinking the POJO

In the previous essay of the Advancing Enterprise DDD series, we looked at a sample POJO with a variety of un-encapsulated persistence concerns. Unfortunately, this exposure occurs right at the heart of our software system: the domain model. Because the domain classes are used throughout the service layer, and are sometimes mirrored through the application layer up to the user interface, our whole codebase is susceptible to misuse of these data. Furthermore, having these data in the domain classes themselves inevitably clouds our thinking when trying to work in terms of the domain and the ubiquitous language. 

Advancing Enterprise DDD - The POJO Myth

This is the third essay in my Advancing Enterprise DDD series, where we discuss doing Domain Driven Design with the standard enterprise Java toolset: Java, Spring, Java Persistence API (JPA), and a relational database (RDB).

In the last essay, we took a higher level view of the design principles of JPA. In this essay, we examine how the JPA-annotated plain-old Java object (POJO) fails to separate persistence-level concerns from our domain classes.

Advancing Enterprise DDD - What Makes It So Hard?

This is the second essay in my Advancing Enterprise DDD series, where we discuss doing Domain Driven Design with the standard enterprise Java toolset: Java, Spring, Java Persistence API (JPA), and a relational database (RDB).

In the previous essay, we reflected on the way the tools we use can affect the way we reason about our domain. In this essay, we look at the high-level design principles of JPA, and how well they align with the principles of DDD.

Advancing Enterprise DDD - Working with the Tools We Have

We’ve done our best to do Domain Driven Design with the standard enterprise Java toolset: Java, Spring, Java Persistence API (JPA), and a relational database (RDB). While this has been a very successful stack for us in developing enterprise applications, we’ve encountered problems doing DDD well in this environment. In this series of essays, we will look at some of the difficulties we’ve had, and consider ways to improve our situation. We provide advice for doing DDD with the given toolset. And we look ahead to how we might do DDD better with different tooling - specifically, replacing Java with Scala, and RDB with a document database such as MongoDB.

Introduce Type Param Pattern

I've always had the feeling that many of the common design patterns were simply recipes for doing something that your programming language does not do for you. The standard Gang of Four design patterns apply to many different programming languages, because these are things that most object oriented programming languages, at least at the time, weren't prepared to help you with. Just which design patterns are relevant is something that changes over time, as languages evolve to do more for you. A classic example is the singleton pattern and Scala. Scala provides singleton objects as a language feature, and most of the implementation concerns addressed by the singleton pattern are now handled by the language.

On the other hand, as languages get more powerful, we expect more from them, and are naturally inclined to attempt to do more sophisticated things than we used to. I often get myself in trouble with Scala, because I try to do things I would never attempt to do in Java. In a position like this, we may need to consider new patterns to get around the newly discovered limitations of the new language. I "invented" a little Scala-specific pattern that I will show here, that I've used to help me overcome a small problem I come across from time to time.

Deconstructing the Cake Pattern

This article provides a technical comparison between using the cake pattern and constructor injection for doing dependency injection in Scala. I show that within a small handful of refactoring steps, we can migrate from the cake pattern to constructor injection. We lose one minor feature along the way. The lost feature is not terribly desirable anyway, and can be emulated with constructor injection if need be. In exchange, we jettison the boilerplate and the opaque nature of the cake pattern.

Catching Up: Writing Again!

So I just finished up this blog post, Just What the Heck is Amortized Constant Time Anyway?, over the last couple weeks. And I felt odd once I finally posted it, because of the total lack of personal context as to where this post is coming from. After all, it's been over a year since my previous post. So I wanted to write a quick "catching up" post, which is mostly about the fact the I am writing again!