Advancing Enterprise DDD - Acknowledgements

Many of the ideas I discuss in this series originated in discussions many years back with two good friends excellent software engineers, Andrew Tolopko and Armen Yampolsky. I am grateful to Armen and Andrew for sparking many different avenues of critical thought regarding JPA, Hibernate, and Domain Driven Design. I would also like to thank Andrew for introducing me to Domain Driven Design in the first place, back in 2005 or so.

Thanks goes to Eric Evans for initially developing the concepts of Domain Driven Design, and presenting them in a book by that same name. This is really a wonderful book that has profoundly changed my way of thinking about software engineering like few other resources have. It was a bit of a challenging book for me on first read, mainly because the ideas he presents were so counter to the ways I typically thought about software engineering. Like many of the best programming books I've read, I didn't really grasp everything the first time through, and I read it a second time in short order. I've read this book three times now, and often re-read sections of it when working on particular problems or challenges. While this book is a little difficult to get through, I highly recommend you give it a read, and keep a copy on your shelf. It's worth the investment.

I would also like to thank Vaughn Vernon for his excellent book, Implementing Domain Driven Design, and for advancing the field of DDD into areas such as CQRS and event-driven architecture. His book provides specific programming and architectural patterns for applying DDD using a variety of technologies, including JPA, and has influenced my thinking here a good deal.

Thanks to the developers of Java, Spring, and Hibernate, for providing a great back-end developer stack that gave me so many employment opportunities over the years. In hindsight, it is easy to focus on all the limitations of this stack, and to overlook it's power and all the ways that it was so innovative for its time. Thanks to Scala and MongoDB for helping the software world take that next step forward.

Thanks to StarUML for helping me produce all the pretty UML diagrams found in this series. Also, thanks to Blogger for providing me with a platform to write and share my work.

Finally, I'd like to thank my family, Josie, Jamey, and especially Shu, for being so supportive of me while I worked through this series. They've been very gracious and patient as I've stolen moments from here or there, and disappeared for brief spells on Sunday nights to post.

Advancing Enterprise DDD - Overeager Fetch

In the previous essay in the Advancing Enterprise DDD series, we investigated how to tailor our cascades and fetch strategies to align with aggregate boundaries. In this essay, we continue to look at fetch strategies in situations where the shape of our aggregates are more complex.

Advancing Enterprise DDD - Cascades and Fetch Strategies

In the last essay of the Advancing Enterprise DDD series, we learned about entity aggregates, and how to construct them while doing domain modeling. In this essay, we begin to look at some specifics of how to implement aggregates using JPA. Specifically, we want to configure our cascades and fetch strategies so that persistence operations align with aggregate boundaries.

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.

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.

Component Based Dependency Injection in Scala

I recently wrote up my experiences using the "cake pattern" for dependency injection in Scala. It grew into quite a lengthy write-up, so I wanted to share it as a PDF in case reading in this blog format is inconvenient:

• Component Based Dependency Injection in Scala.pdf

The same content appears below, but please be warned that the internal links are broken, and the code formatting is not to my liking: