I finished reading a book. It took me 3 years to get through its slim 100 pages, but that's mainly a product of my reading habits. Still, you get a book review.
Domain-Driven Design Quickly - Floyd Marinescu, Abel Avram
This slim volume summarizes the many dense concepts of domain-driven design, a software engineering philosopjhy that seems borne of certain dense problems in enterprise software engineering. That gives you some idea of whether it would be of interest to you. The ideal audience is probably someone with some software engineering experience who has heard of some terminology of DDD - maybe in a positive context, maybe not - but wants to better understand, without yet having gone through the investment of the longer foundational works of the topic (like the "Blue Book", Domain-Driven Design by Eric Evans).
Reading it feels like a fever dream, an fast infoburst of terminology and the outline of big concepts, bold declarations of terminiology with capital letters. My honest initial reaction was mild skepticism in truth - isn't this too much complexity? How could these extra layers of engineering lead to a better product, or let me keep my job?
As presented, it's more of a methodology than an explicit philosophy, at least in this text, but the dense text itself hints at a philosophy: that the actual real-world impact of the software is what matters, that software must be aligned with the real world, and that the way to deal with complexity is by embracing complexity, difficulty, up-front decision making and (contrarily) the inevitability of change. You must plan the tower and build the tower, and yet know it will not stand for long.
I praise small books like this, because I might never get around to reading the longer books, and then can only go off blog-posts and vibes to just such a philosophy. There are caveats: I'm sure there is depth and motivation that I'm missing, and if I don't reject the ideas I'm as likely to apply them out-of-context with a zealot's misplaced zeal. But that was always step one of understanding new ideas, and I appreciate this book getting me to that step.
(Also: there really should be more short, dense and opinionated books about software engineering! In part, because clearly I cannot get through books that are much longer, and perhaps partially because I yearn for the form-factor and aeasthetic of zines and self-published tabletop RPGs. But I digress; it is not yet time to write my zine-length book about software.)
#books #software
-----