2015-03-29

Advancing Enterprise DDD - The Entity and the Aggregate Root

In this essay of the Advancing Enterprise DDD series, we will leave behind the POJO for a bit, and look at entity aggregates. After the entity, the aggregate is probably the most important building block in Domain Driven Design. Aggregates provide a way to organize your entities into small functional groups, bringing structure to what might otherwise be a knotted jumble of entity classes.

2015-03-25

Scala EE Discussion Group

I feel like Scala is poised to become the successor to Java on the JVM. But migrating from large-team Java and Java EE presents many challenges. For instance, what to do to assure a comfortable level of stylistic uniformity throughout the codebase? What if your senior engineers want to use, say, scalaz, and you're worried that the mid- and junior-level developers on your team won't be able to understand it? Just which technologies should you choose, and how do you know they are robust and stable? I've created a Google+ group for Java EE expats (and their loved ones) to discuss issues like this. Please stop by and share your thoughts.

https://plus.google.com/u/0/communities/117718481990251882678

2015-03-22

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. 

2015-03-15

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.

2015-03-08

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.

2015-03-01

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.

2015-01-08

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.