What do you think?
Rate this book
Lean Architecture: for Agile Software Development
More and more Agile projects are seeking architectural roots as they struggle with complexity and scale - and they're seeking lightweight ways to do it
384 pages, Paperback
First published August 3, 2010
30 people are currently reading
370 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 15 of 15 reviews
February 27, 2016
Find a detailed review at my blog.
The book heads for DCI as a Lean and Agile architectural style, that is understood. My main objection would be, that the book builds a very one-dimensional picture of architecture, declares DCI as a kind of Holy Grail. It completely misses one of my main architectural concerns, namely the balancing of NFRs: robustness, security, availability, and others (transactions, anyone?). The book emphasizes only one NFR: maintainability. But what happens, if others are far more important? How do they combine with DCI's tradeoffs? To be fair, the authors declare them out of scope early on, and the combination of DCI with those other NFRs might be worth another book. Which I'd like to read!
The book heads for DCI as a Lean and Agile architectural style, that is understood. My main objection would be, that the book builds a very one-dimensional picture of architecture, declares DCI as a kind of Holy Grail. It completely misses one of my main architectural concerns, namely the balancing of NFRs: robustness, security, availability, and others (transactions, anyone?). The book emphasizes only one NFR: maintainability. But what happens, if others are far more important? How do they combine with DCI's tradeoffs? To be fair, the authors declare them out of scope early on, and the combination of DCI with those other NFRs might be worth another book. Which I'd like to read!
August 23, 2012
I can't recommend this one. Such a shame. There seems to be such a bounty of useful patterns and ideas hiding away just below the surface in Copliens most recent book.
Unfortunately the writing style and endless digression overshadows even the chapters on DCI which are otherwise very interesting.
While Coplien struggles to revive many software development practices of the last 3 decades by telling us that they are lean and agile, the arguments are seldom very convincing and at times it seems that Coplien considers the agile community adolescent and naive.
Indeed a very strange book, because, if one manage to struggle through the book, there are rewards: A very interesting discussion on focusing on form in architecture instead of structure. A great piece on how develop architecture into the working code to guide future design. I also enjoyed the scattered pieces on seperating the domain model from the mental model of the end user. These pieces, taken seperately, would be note worthy as articles or blog-posts. Now they are unfortunately buried away in the book.
Unfortunately the writing style and endless digression overshadows even the chapters on DCI which are otherwise very interesting.
While Coplien struggles to revive many software development practices of the last 3 decades by telling us that they are lean and agile, the arguments are seldom very convincing and at times it seems that Coplien considers the agile community adolescent and naive.
Indeed a very strange book, because, if one manage to struggle through the book, there are rewards: A very interesting discussion on focusing on form in architecture instead of structure. A great piece on how develop architecture into the working code to guide future design. I also enjoyed the scattered pieces on seperating the domain model from the mental model of the end user. These pieces, taken seperately, would be note worthy as articles or blog-posts. Now they are unfortunately buried away in the book.
March 6, 2014
I wish the star system was different: I didn't like it, but that doesn't mean that I thought it was awful. I didn't like the chatty style of "grandpa Harry" or the authors' comments to the reader "nerds". Some people clearly don't mind this apporach, but I don't like it. Save the comedey for comedies.
My main criticism is that I thought it didn't explain the subject and eneded up offering platitudes like "try really hard" and "concentrate" and "think long and hard before..."
This book is destined for the charity shop.
My main criticism is that I thought it didn't explain the subject and eneded up offering platitudes like "try really hard" and "concentrate" and "think long and hard before..."
This book is destined for the charity shop.
July 28, 2016
There's a set of great software patterns in here, waiting to get out. Digressions, namedropping, a very particular history of OO get in their way. Wait for the 2nd ed.
March 20, 2017
J. Coplien tells us how to strike the right balance between Agile and Lean: A touch of up-front design to stabilise the architecture (i.e., the form) and reduce later rework, as opposed to fully reactive/agile approaches. Practically, J. Coplien first builds use-cases and uses the Data-Context-Interaction architecture (DCI) to code them.
As for the content, I perceive the importance of roles, and in turn, the benefits of the DCI architecture. Yet, I am sceptical about capturing the mental model of end-users. Different end-users may have a different mental model and I am not sure how this would help make the code clearer for the developer, who may have yet another mental model of the domain. I feel more convinced by Evans's approach (see Domain-Driven Design: Tackling Complexity in the Heart of Software), where it is the shared team mental model that matters.
As for the presentation, while I understand that explaining a nuance between Agile and Lean takes time, I still found the beginning very, very lengthy. As I understand it, the DCI architecture—the meat—starts on the next to last chapter, that is the last 50 pages.
As for the content, I perceive the importance of roles, and in turn, the benefits of the DCI architecture. Yet, I am sceptical about capturing the mental model of end-users. Different end-users may have a different mental model and I am not sure how this would help make the code clearer for the developer, who may have yet another mental model of the domain. I feel more convinced by Evans's approach (see Domain-Driven Design: Tackling Complexity in the Heart of Software), where it is the shared team mental model that matters.
As for the presentation, while I understand that explaining a nuance between Agile and Lean takes time, I still found the beginning very, very lengthy. As I understand it, the DCI architecture—the meat—starts on the next to last chapter, that is the last 50 pages.
April 2, 2014
My review seems to be aligned with that of the majority of the readers of this book... My initial feeling was great because the topic of agile architecture has been a pretty hot one at work recently and I thought this book hit the exactly the right spot. However, after reading it (up to the DCI chapter) I have the feeling that I can't remember anything I read. Sure, I made a lot of notes, underlined plenty of rows and so on, but the underlined rows are here and there, one line on this page, a couple on the next... so the good ideas are scattered all over the place, and I didn't get a really good overall idea about agile architecture.
Furthermore, I think the book talks way too much about both the philosophical side of agile as well as the very basic stuff. I could've skipped all that and move directly to talk about agile architecture.
I won't bother reading the DCI chapter. I don't want to be given an architecture, I want to learn how to maneuver in an agile environment, as an architect, building whatever type of architecture is required to do the job.
Furthermore, I think the book talks way too much about both the philosophical side of agile as well as the very basic stuff. I could've skipped all that and move directly to talk about agile architecture.
I won't bother reading the DCI chapter. I don't want to be given an architecture, I want to learn how to maneuver in an agile environment, as an architect, building whatever type of architecture is required to do the job.
March 29, 2016
One of the very best books I've read on software architecture in the last few years. It takes an action-oriented approach, but not as a cookbook, but as a framework for introducing other concepts. I use the terminology of "modules vs joints" very regularly, and I found myself nodding all throughout the passages that are just "fluffy" enough to be valuable.
Would I recommend this book? That depends. It requires a certain readiness of mind that not everyone has, and if you come at it thinking it will teach you software architecture, you'll be knee-deep in the code samples without learning anything.
Would I recommend this book? That depends. It requires a certain readiness of mind that not everyone has, and if you come at it thinking it will teach you software architecture, you'll be knee-deep in the code samples without learning anything.
March 25, 2013
I enjoyed this book. It is not the technical detailed code walkthrough I was expecting. Instead it is a thorough examination of how to approach software architecture from both Agile and Lean first principles. Central to this examination is the lean secret of "the whole team" and the agile principle of "people and interactions over processes and tools". This book provides a number of interesting ideas with which to mull over and experiment.
I can't wait to share this book with my team.
I can't wait to share this book with my team.
June 10, 2012
This book contains some very valuable insights into the nature of software architecture. Unfortunately, the writing style is a bit verbose and contains many repetitions, which (ironically) isn't very lean. Nonetheless, this book is worth a read, if only because of the introduction to the DCI framework, an interesting way of separating 'what the system does' from 'what the system is'.
January 17, 2014
It took a long time to read, but not because it is not intuitive enough. It's just too much meat in this meal to eat at once. Is a very good reading about all topics from culture to technology in software development, worth reading, but don't use it as a reference-implementation guide, use it as a source of knowledge.
PS: It also has very good resources and quotes on it, it's a keeper.
PS: It also has very good resources and quotes on it, it's a keeper.
June 17, 2012
Overlong and overdone. The code examples are in c++ (why?) and non-idiomatic Ruby. I was mostly interested in how to apply DCI, but by the time the author actually got to the concret DCI examples I was just ready to be done with this book.
April 21, 2013
I found it hard to get through the book. I still fail to understand exactly what's the point of dci. I had a few reveleations where I thiught I did understand it, but every time reading further and learning more about it, especially in this book got me more confused.
September 24, 2013
Everybody, all together, from early on
Surely, it is a opportunity to take a walk into the world of the software architecture. Some sections aren't much easy to understand, anyway from my point of view, it could be considered a milestone about the topic.
Surely, it is a opportunity to take a walk into the world of the software architecture. Some sections aren't much easy to understand, anyway from my point of view, it could be considered a milestone about the topic.
September 18, 2011
There're some nice bits in it, but it's much to verbose for my taste. The main thing I took from it is the difference between form and design.
September 17, 2016
Muy bueno el contenido, pero mal estructurado y con una redacción confusa.
Los conceptos explicados son muy buenos, pero se encuentran distribuidos sin una estructura clara!
Los conceptos explicados son muy buenos, pero se encuentran distribuidos sin una estructura clara!
Displaying 1 - 15 of 15 reviews