Not sure why you would want this. I know him from the book “Clean Code” and the Clean Code Architecture (not the book, mostly his blog posts on the topic). He oversells his points a bit too often, is IMHO too dogmatic, and I don’t necessarily like his writing style, but his content offers some great hindsight and interesting observations regarding software development.
And worse, people take it all at face value and don't think for themselves.
A lot of the "clean" stuff is completely out of date. It might have been justifiable to insert umpteen independent layers (ooh.. Data Objects -> Domain Objects -> UI objects; mapper mapper mapper!) into your software in the early 90s when everything was a monolith and there were such things as "database teams" and "business rules teams" in order to insulate those parts of the software from each other.
In the age of uServices where the boundary is the API and the context is completely self-contained, it's not just a bad idea it's an actively malignant waste of time.
Comments
Not sure why you would want this. I know him from the book “Clean Code” and the Clean Code Architecture (not the book, mostly his blog posts on the topic). He oversells his points a bit too often, is IMHO too dogmatic, and I don’t necessarily like his writing style, but his content offers some great hindsight and interesting observations regarding software development.
And worse, people take it all at face value and don't think for themselves.
A lot of the "clean" stuff is completely out of date. It might have been justifiable to insert umpteen independent layers (ooh.. Data Objects -> Domain Objects -> UI objects; mapper mapper mapper!) into your software in the early 90s when everything was a monolith and there were such things as "database teams" and "business rules teams" in order to insulate those parts of the software from each other.
In the age of uServices where the boundary is the API and the context is completely self-contained, it's not just a bad idea it's an actively malignant waste of time.