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.

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

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.