Beautiful Architecture Chapter 4: Making Memories

I wish every chapter in the book were like this one. I loved that the chapter discussed abstract, high-level architectural principles and then discussed how those principles were implemented in the real world! I've read so much strategy (though I still have a long way to go before I can call myself a n00b of an architect), it's great to finally get some of the tactics.

I found the layers of the architecture from bindings through the application facade quite interesting. The need for decoupling between the domain model and the UI is something that I've learned the hard way on many projects. As Fredrik Kjolstad mentioned in his blog post on this chapter, the pattern takes a lot out of the MVC playbook, and MVC + application facade = decoupled & testable layers.

I think that I'll definitely have to re-read the sections on bindings, properties, forms, and the application facade to really comprehend what each is doing, but I like the sound of the stack on my first read.

I did get the feeling that the example about needing to capture a rewards club member's club number and expiration date bleeding into UI logic as "if this checkbox is selected, then enable these four other text fields" was going to have that logic put into the forms layer. This is definitely better than having it in the UI from the view of testability, but my gut feel is that business logic can still become scattered if some is in the forms layer and some is in the domain layer.

I also didn't comprehend the incredible power of the bindings layer that the author was so proud of, likely because I haven't had the misfortune of experiencing headaches that would have been prevented by such a layer . The forms layer seems like enough abstraction between the screens and the app facade.

I was a little surprised to read that every form has its own application facade. There seemed to be a one-to-one relationship between screens, forms, and application facades, in which case a change to your domain model doesn't feel like it would be very shielded from the rest of the app. You'd end up changing as many files as if there were no abstractions and the UI was bound to the domain model instead of the application facade. On the other hand, it seems necessary for there to be a one-to-one mapping so that the facade can return the domain model projected and flattened just the way that particular form & screen need it. What am I missing here?

The resiliency built into the application was impressive. I also liked the fact that it had a useful, perhaps unintended consequence. The fast and slow retry methods meant that a StudioServer could be taken off-line for an upgrade without all StudioClients having to stop working. As soon as the StudioServer was back up and responsive, the StudioClients would complete their transfers.

I liked how the team applied Conway's Law and created a DvdLoader for the PCS team to interact with so that their team could maintain full control of the DVD's layout.

This chapter also introduced another simple yet useful decomposition of architecture: what must it do and what boundaries must it work within?