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 - Moving Forward

In the last essay of the Advancing Enterprise DDD series, we wrapped up our discussion on immutability, as well as the technical discussion overall. In this essay, we wrap up the series by reflecting on what we've learned, and discussing how to apply these lessons as we move forward.


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.


Down Time

Some things have come up in my personal life that I need to attend to. I'm not going to stop writing and coding entirely, but it's going to have to take a lower priority for the next few weeks while I take care of things. I'm going to finish the Reactive Scala course, and I'll be able to complete the Advancing Enterprise DDD series on schedule. But the emblem documentation will be delayed, and my release dates for longevity are going to have to get pushed back.

Thanks for your patience, and thanks so much for your readership! I love to write. It really helps me formulate my thoughts and work them through. But it's especially fulfilling to have people reading what my material.


Advancing Enterprise DDD - Documents as Aggregates

In the last few essays of the Advancing Enterprise DDD series, we've taken a look at entity aggregates, and the challenges we face in implementing them well. We've seen a great many techniques we can employ using JPA to mitigate these challenges. In this essay, we step out of the JPA and relational database mindset, and consider modeling aggregates with a document database such as MongoDB.