I really like that book, and the concepts presented there. Here some comments to make you more happier about this book. I don't have access to the book right-now, I will not be able to give precise references. I will have to buy this book again. I could buy yours ;)
The Goal of architecture is addressed right at the start in the introduction. He won't go into details but it's clear. The goal of architecture is to optimize people work, not the system. Given a flat listing of all the code for a system, without boundaries or already decoupled classes into components, you and me, with different set of constraints won't derived the same architecture. Both being "optimized" for our own purposes. So there is no path to follow.
Also, adding to that, software is a living beast. You may have optimized your architecture for today, but some other day, you have to admit, things have changed. The environment, the teams, the tools, the software...
You focus a lot on the SOLID principles, but those are at the design level. They are the foundation to understand the package principles. You have to focus more on those 3 package principles and the tension space they form (it's all about compromise).
The book is about teaching principles. The recipe is following them.
Comparing Clean Architecture with Code Complete isn't fair, or is comparing apples and oranges. Code Complete is at the code level/line level. At most considering a couple of lines together, to form a class definition or a function. The scale and complexity of such elements are small and simple (but I won't explain them to my Mom ;) ). Opposite to that, in the continuum describe in the book, is architecture. You draw rectangles and arrows, but the complexity implied is so huge.
Chapter 2 is my best : A Tale of Two Values. If you have to convince a non-techy-manager-feature-oriented-I-know-nothing-about-software-development to let you structure your code, that is doing architecture, that chapter could gives you bullets. Otherwise, you will craft a Monolith. Because, you won't get up a morning with the idea "Lets build a Monolith today". Those managers make you build one (and yes, we let them do). And it's also typical for a start-up, where you have to focus on features.
I will certainly give a try to "Patterns of Enterprise Application Architecture", by Martin Fowler. I really like his work. And I totally agree (finally) that "The chapters on design paradigms (structured, object oriented, and functional) seem particularly out of place and unnecessary." I also appreciated the appendix recapping Bob's career and the polymorphisme applied to hardware.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I really like that book, and the concepts presented there. Here some comments to make you more happier about this book. I don't have access to the book right-now, I will not be able to give precise references. I will have to buy this book again. I could buy yours ;)
The Goal of architecture is addressed right at the start in the introduction. He won't go into details but it's clear. The goal of architecture is to optimize people work, not the system. Given a flat listing of all the code for a system, without boundaries or already decoupled classes into components, you and me, with different set of constraints won't derived the same architecture. Both being "optimized" for our own purposes. So there is no path to follow.
Also, adding to that, software is a living beast. You may have optimized your architecture for today, but some other day, you have to admit, things have changed. The environment, the teams, the tools, the software...
You focus a lot on the SOLID principles, but those are at the design level. They are the foundation to understand the package principles. You have to focus more on those 3 package principles and the tension space they form (it's all about compromise).
The book is about teaching principles. The recipe is following them.
Comparing Clean Architecture with Code Complete isn't fair, or is comparing apples and oranges. Code Complete is at the code level/line level. At most considering a couple of lines together, to form a class definition or a function. The scale and complexity of such elements are small and simple (but I won't explain them to my Mom ;) ). Opposite to that, in the continuum describe in the book, is architecture. You draw rectangles and arrows, but the complexity implied is so huge.
Chapter 2 is my best : A Tale of Two Values. If you have to convince a non-techy-manager-feature-oriented-I-know-nothing-about-software-development to let you structure your code, that is doing architecture, that chapter could gives you bullets. Otherwise, you will craft a Monolith. Because, you won't get up a morning with the idea "Lets build a Monolith today". Those managers make you build one (and yes, we let them do). And it's also typical for a start-up, where you have to focus on features.
I will certainly give a try to "Patterns of Enterprise Application Architecture", by Martin Fowler. I really like his work. And I totally agree (finally) that "The chapters on design paradigms (structured, object oriented, and functional) seem particularly out of place and unnecessary." I also appreciated the appendix recapping Bob's career and the polymorphisme applied to hardware.