Category: Architecture

Design pattern books:

1.       C# 3.0 Design Patterns

2.       Design Patterns: Elements of Reusable Object-Oriented Software:

3.       Patterns of Enterprise Application Architecture

This book is a must

4.       Microsoft .NET: Architecting Applications for the Enterprise (Pro-Developer)

5.       Microsoft Application Architecture Guide (Patterns & Practices) (This one can be downloaded for free as PDF from msdn)

6.       Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (This book is really good for specializing in middle tier aka services, queues etc)

7.       Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition)

 

 

 

Domain Model Pattern (These books are dealing only with the DM pattern)

1. Applying Domain-Driven Design and Patterns: With Examples in C# and .NET

It has examples in C# 2.0 but the concept (DM) is still valid nowadays.

2.       Domain-Driven Design: Tackling Complexity in the Heart of Software

This is a classic although the book is a bit dense, see the examples. The book is narrated as a story when the author was developing an application for embedded electronic circuits.

 

Inversion of Control Pattern/IoC:

3.       Dependency Injection

Internet Architectures (Load balancing, redundancy, ways to scale out)

4. Scalable Internet Architectures

5. The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise

These two are “must have”references, specifically the UML one:

6.       UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)

7.       Refactoring: Improving the Design of Existing Code

And to translate from the Object Oriented World, Class Diagrams and UML notation to the Entity Relational World with Entity Relationship Diagrams:

8. Agile Database Techniques: Effective Strategies for the Agile Software Developer (Wiley Application Development)

9.       Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler))

Thanks to Srinivasa Tammana for asking me to put this list together. I own other titles but they are more detailed to a particular database technology or programming language and the books here are long time favorites.

Cheers
Lizet

I was reading the IASA forum and found this article that summarizes a few truths about project estimation. I’ve been more than once haunted by time estimates I’ve given and I tend to be very conservative, to the point of having my estimates always frown upon.

Here are some tenants:

1.    It is relatively easy to estimate what you know.
2.    It is difficult to estimate what you know you don’t know.
3.    It is very difficult to estimate what you don’t know you don’t know.

And here is a thought that makes more sense to me. Having tried waterfall, mandate, wishful thinking from management etc in my many years as developer, this to me makes more sense:

Agile is not an estimation methodology in and of itself, and it does not generally develop estimate in units of time. Instead, estimated units of work are used. The units of work do not directly map to time until you have calculated your team velocity. Once the velocity is determined, it can give you a pretty good idea as to how long it will take to complete your project – that is for the body of work in the project that you know of and understand.

And here is the link to the complete article, it is worth reading every line with attention :)…

Are we there yet?