A good second book about arquitecture RRS feed

  • General discussion

  • Hello

    I have finished "pro scalable application in .net 2.0" which was nice. Now I want to read another book about architecture. What do you recomend?

    I think Domain-Driven Design: Tackling Complexity in the Heart of Software  is a good option, do you know another?


    Wednesday, April 12, 2006 11:01 AM

All replies

  • DDD is a good book - however it deals with a certain narrow aspect of architecture. I would recommend reading "Software Architecture in Practice" by Len Bass, Paul Clements and Rick Kazman before that.



    Wednesday, April 12, 2006 11:25 AM
  • I second Arnon's suggestion.  I also enjoyed Software Architect Bootcamp.
    Wednesday, April 12, 2006 7:50 PM
  • Tim,

    Can you comment on why you like Software Architect Bootcamp. I've thought about reading it, but it doesn't have good reviews on Amazon.

    Thursday, April 13, 2006 3:44 PM

  • I find Amazon.com "the user who bought/reviewed this book also bought/reviewed this as well" piece of advice usually helpful.

    Searching the blogs would be even better, because athors tend to explain in more details what they like or think about the book, unlike the review which might be written by the publishers/authors themselves.

    In my personal experience, I find MSDN articles, blogs and expert websites (Codeguru and Codeproject - or Codezone) are much more helpful then books. The feedback, the actuality, the response, corrections, real-world samples - books can+t match this.
    Friday, April 14, 2006 8:57 AM
  • I use all resources, including books. Web sites generally don't provide enough beginning to expert information. As for Microsoft sites, while I use them, I've found their examples and articles to provide too much detail without providing the basics. Or, when showing sample code, they provide way too much extraneous code that does not apply to the topic.
    Friday, April 14, 2006 3:02 PM
  • I agree with Arnon.

    The is also excellent for Software Architecture: Software Systems Architecture

    This is cool, I saw it's coming in June.  The Java version (Agile Principles, Patterns, and Practices) was excellent, but I look foward to re-reading the C# version.

    An old review I did of DDD:
    This book is good for small projects and small teams, or for using the techniques found in it for module level analysis.  The author attempts to apply his thoughts to large projects, but they would be extremely hard to apply or pull off.  He has some great thoughts on how to absorb domain knowledge, but goes over board bashing the Unified Process and other proven techniques.  He isn't coming up with anything new, but he does do an excellent job of creating a book.  It is very well organized.  BTW, if I thought that XP could be pulled off anywhere in the world, with any group of programmers, this book would get a 10+ rating.  I think XP works but only in very specific environments.  Most environments do not allow for an enterprise level effort of XP.

    Here are the books I recommended to my team:

    .NET 2.0, Patterns, Architecture, OOAD, Books and Links


    Friday, April 14, 2006 7:16 PM
  • Sorry for taking a while to respond.  I actually went out and looked at the reveiws on Amazon.  I guess it depends on what you are looking for as to whether it will be of benefit.

    If you look on Amazon there is a review that is titled "A game in two halves."  This is the way I view the book as well.  I really liked the description of the attitude needed and how an architect should conduct their job.  That is what stuck with me.  I don't really remember it as a technical book.

    Hope that helps.

    Friday, April 14, 2006 9:06 PM
  • Hi Tad,

    I agree of course that no solution fits every problem... What are the characteristics of an environment where XP works in your opinion?

    Best Regards,

    Sunday, April 16, 2006 6:52 PM
  • Hello Jimmy,

    My view on XP is summarized in the first paragraph of this blog.

    Good luck with your upcoming release!!!  Hope you do well, and look forward to checking it out myself.



    Monday, April 17, 2006 12:29 AM
  • Hi Tad,

    Thanks, that was an interesting read!

    You sound very positive to XP, for the right context. Does that mean that you also try to "move" projects actively to that kind of context? Or is it better to accept the context and go with another approach in your opinion?

    And thanks for the good luck wish!

    Best Regards,

    Monday, April 17, 2006 7:03 PM
  • I would never discourage moving towards XP if I thought the environment was right for XP.  I tend to have the following criteria that must be met before moving in that direction:


    Small highly disciplined self contained team which includes end users of the system.

    Gurus in the technology and domain being used.

    The software built will be maintained and modified in the future by the same crew building it.

    A project manager that has the qualifications to create an environment for a very high quality communication network.

    Team members that are open to the XP intensity created in the environment, and are qualified to handle it.

    No outsourcing of any part of the project at all.


    There are a lot of places I have seen that would benefit from XP, but it has been hard to get across to them that it is actually a strict process.  TDD is viewed by many places as a process for setting up regression tests on modules already coded.  TDD in it true context is a discipline that is hard to sell in many shops.  Most people think XP opens the door to be able to create half ass documentation, have no real communication channels, and that it frees them up to use their own home brewed process and they just label it agile.  They have taken parts of XP and morphed it into some mess that is not workable.


    They don't understand that it actually comes with it own very strict rules and process steps that require the best of the best to implement.


    I have found few shops that are capable, but would never discourage a shop that I thought was capable.


    It always depends on the team, and the project the team has to be fit into.  I use the UP most of the time.  But I use it in a very iterative way.  If the team is capable of handling XP exercises we will introduce them, if not we use the process to guide the team and do the opposite of what XP says, which is team (people) before process.  In my opinion the team must be mature enough to handle the responsibility.  I find few teams are.


    I also run into more and more outsourced part of the project.  Off-shore has eliminated the working software over comprehensive documentation.  We need high ceremony documentation in order to set up a contract between the local team and the off-shore team.  This falls under the guides in CMMI.  We treat our off-site and off-shore teams as a contracting entity, and therefore must product the high ceremony documentation to allow for a thorough communication vehicle to be in place.


    Like I said if XP is a viable methodology for the site I would never shoot it down, I just haven't found many places the contain the teams that are capable of the high degree of discipline required to pull it off.

    Monday, April 17, 2006 8:41 PM
  • Thanks to all of you, but i am looking for something different, do you know any book that speak deeply about soa, n-tier, etc etc.. ? And all the examples in .net :)
    Monday, April 17, 2006 9:31 PM
  • I haven't read this one - but I really disliked his other book (Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services)

    The best SOA book I read thusfar is Enterprise SOA : Service-Oriented Architecture Best Practices  (though it might not be what you are looking for as it doesn't have any source code samples nor is it .NET oriented)



    Monday, April 17, 2006 10:12 PM
  • You may also want to consider this one.  It seems to touch on a lot of areas you've listed.  You will have to wait until it is released though.


    Tuesday, April 18, 2006 12:59 AM
  •  Arnon Rotem Gal Oz wrote:

    I haven't read this one - but I really disliked his other book (Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services)

    The best SOA book I read thusfar is Enterprise SOA : Service-Oriented Architecture Best Practices  (though it might not be what you are looking for as it doesn't have any source code samples nor is it .NET oriented)



    Arnon is right, that is the best book out on SOA.

    Tuesday, April 18, 2006 1:01 AM
  • Tad, when you discuss the scaling up to larger projects .. do you not think things like bounded contexts do a a good job of handling this? I have used alot of thoughts from DDD on medium->large projects and found bounded contexts to be the key in scaling DDD because you are right the first 12 chapters or so don't work very well with large teams ... but bounded contexts seems to do a pretty good job at breaking up a large team into many small teams (including dictating how the teams interact with each other)
    Friday, April 21, 2006 8:20 PM
  • I have not found the skill sets available on a team to handle the last half of the book.

    Remember I am only talking from experience.  One of the things I believe is needed for XP to work is a set of gurus working together.  I have not seen a team I would trust with the extra effort required to pull it off on a large project.

    UP is so much easier to pull off I don't know why I would want to go to all the extra effort involved with XP unless it was a small team, working on a small project.


    Saturday, April 22, 2006 1:26 PM
  • I recommend Patterns of Enterprise Application Architecture. Although it is somewhat small, I think it is an excellent book.
    Sunday, April 23, 2006 12:45 AM
  • As the books P of EAA and DDD have both been mentioned in this thread (and the author of the book I'm recommending is commenting in this thread :)). I think it is a great time to mention that Jimmy Nilsson's new book actually discusses large area of both of these works in conjunction with each other :)


    Monday, April 24, 2006 1:29 AM
  • The main thing required to implement bounded contexts is a strong architect and management willing to follow. Seperating a group into sub-groups is a quite common task, the difficulty is in assigning the communication methodologies for these groups and the groups having the discipline to follow.

    If you setup a process based upon managerial buy in and the developers ignore it ... It becomes a management issue to insure that you receive compliance.


    Monday, April 24, 2006 1:35 AM
  • Agreed- Enterprise SOA : Service-Oriented Architecture Best Practices is the best one out there.
    Friday, August 11, 2006 1:46 AM