![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Classic, rather than a classic
Book Review: Domain-Driven Design - Tackling Complexity in the Heart of Software, by Eric Evans
I'd been aware of this book for quite a while, and when it was heavily reduced on Kindle I decided the time was right. I wondered whether it would reveal that I'd been doing it all wrong for years, or whether I was doing it right without attaching the right names to things.
It's a mixed book. I found the early discussion on entities, value objects, and repositories, illuminating in that they clarified what I already intuitively understood. But whilst there was nothing to object to in the later parts of the book, it didn't really retain my attention. Published in 2004, it hasn't aged well. This may be a reflection on my personal technology stack. The code examples in the GoF Design Patterns are generally written in C++ or Smalltalk, and so were never all that familiar to me. Here, the code examples are in Java - and it's Java without generics, it's Java with entity beans, that's how old it is.
There's a whiff of Conway's Law to it as well. Design choices can be political and organisational, as well as technical. Here one senses the stale bureaucracy of enterprise software, which certainly isn't dead, but is something I suggest most enthusiastic techies would tend to avoid in a way that perhaps wasn't possible a decade or more ago. Enough companies have woken up to the need to devolve control, and to get success from that. The concepts are still valid, but the way they are presented does not always feel all that relevant.
I'd been aware of this book for quite a while, and when it was heavily reduced on Kindle I decided the time was right. I wondered whether it would reveal that I'd been doing it all wrong for years, or whether I was doing it right without attaching the right names to things.
It's a mixed book. I found the early discussion on entities, value objects, and repositories, illuminating in that they clarified what I already intuitively understood. But whilst there was nothing to object to in the later parts of the book, it didn't really retain my attention. Published in 2004, it hasn't aged well. This may be a reflection on my personal technology stack. The code examples in the GoF Design Patterns are generally written in C++ or Smalltalk, and so were never all that familiar to me. Here, the code examples are in Java - and it's Java without generics, it's Java with entity beans, that's how old it is.
There's a whiff of Conway's Law to it as well. Design choices can be political and organisational, as well as technical. Here one senses the stale bureaucracy of enterprise software, which certainly isn't dead, but is something I suggest most enthusiastic techies would tend to avoid in a way that perhaps wasn't possible a decade or more ago. Enough companies have woken up to the need to devolve control, and to get success from that. The concepts are still valid, but the way they are presented does not always feel all that relevant.