⌊ K™¦krizzna.web.id ⌉

This is a really good book. It has great information that is difficult to find in other places. However, as I read the book, it is becoming extremely evident that it is written by two different authors.

Overall review: Poor editing makes it difficult to grasp the authors’ points.

The following sentence from Chapter 1 perfectly exemplifies the book’s writing:

[The word "architecture" is indissolubly bound to the world of construction.]

Indissolubly?

It feels like one author says something, then the other author jumps in and says, “Oh, but I think…” This creates a kind of jumbled writing that doesn’t flow.

Some of the sentences don’t parse quite right in English and seem to distort the meaning. Precise language is needed for book a book that is describing a precise process like Software Architecting. The imprecise language makes the book feel sloppy.

For example:

“As you can see in Figure 1-1, the Architecture is described by one Architectural Description.”

This should really read: “…is described by one [possible] Architectural Description.”

The following is just a jumbled sounding sentence that could mean a great number of things:

“At the end of the day, you serve different and concurrent views of the same architecture and capture its key facts.”

Those are short samples of something that is better shown by the long example below (between the [[--- and ---]]. In the sample below the authors speak about a [border]. They explain it one way, then throw in an unneeded analogy about apples, and then bend the understanding of the [border] into another explanation. After reading this section, it’s quite confusing to grasp their point.

[[---

Defining the Borderline Between Architecture and Implementation

The constituent components you identified while breaking down the system represent logical functions to be implemented in some way. The design of components, their interface, their responsibilities, and their behavior are definitely part of the architecture. There's a border, though, that physically separates architecture from implementation.

This border is important to identify because, to a large extent, it helps to define roles on a development team. In particular, it marks the boundary between architects and developers. Over the years, we learned that architects and developers are not different types of fruit, like apples and oranges. They are the same type of fruit. However, if they are apples, they are like red apples and green apples. Distinct flavors, but not a different type of fruit. And neither flavor is necessarily tastier.

You have arrived at the border between architecture and implementation when you reach a black box of behavior. A black box of behavior is just a piece of functionality that can be easily replaced or refactored without significant regression and with zero or low impact on the rest of the architecture. What's above a black box of behavior is likely to have architectural relevance and might require making a hard-to-change decision.

What's our definition of a good architecture? It is an architecture in which all hard-to-change decisions turn out to be right. ---]]

Rating: 3 / 5

For a long time I have been searching for a good & easily understandable book on application architectures & patterns and finally my search ended with this book.

I have read P of EAA Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) before but this book provides good context and examples around each of the patterns mentioned in P of EAA.

couple of -ves I see in this book are,

1) there’s no clear-cut examples for certain concepts that authors are trying to make in the book (e.g. application logic vs. business logic)

2) Although it provides good overview of all patterns including the ones related to yesterday’s architecture (e.g Transaction script) I think more info, examples, best practices should have been provided on patterns more relevant to today’s Enterprise applications (e.g. domain model)

Never-the-less I would recommend every architect to keep this in their reference library.
Rating: 4 / 5