In this 4+ hour series Bob talks about architectural decisions that will influence the design and development of your application. He aggregates information from a dozen of the most important books on Software Architecture today to provide a fundamental set of principles, guidelines, patterns and practices you should follow for your next project. The series mainly focuses on the Layered Architectural Pattern as a first steps towards mitigating the effects of change on your software development efforts. He explains vital principles like Separation of Concerns, coupling, cohesion, DRY, YAGNI, dependency injection and much more. This series should help you put all the pieces together to build more robust enterprise scale applications.
I’m thoroughly enjoying this new series. It’s answering a lot of questions for me. Your videos have great style and a wonderful teaching ethos. Thank you and keep up the good work.David C. 1/24/2013 via Lifetime Member Q&A
Bob, you’ve made my year. I hold a Masters degree in Software Engineering and YET no one has taught me in all my years of study (including books) and development, what you have managed to teach me in a few hours. My life-membership is peanuts in comparison to what I’ve learned in this course. You’ve answered the exact questions I have been struggling with for the past few years but never had the time or the patience to go through a specialized book to find them. My naive attempt at architecting my desktop software has yielded a common model side-layer shared by all layers and each top layer depending directly only on the layer beneath it (embarrassingly that includes the Business Logic dependence on the Data Access layer). I never understood the purpose of IoC until you’ve explained it so clearly here. I’ll watch the new Applied series to learn the inner workings of it so I may re-implement my solution.Ali A. 5/15/2013 via Lifetime Member Q&A
I just added a followup series: Applied Architecture – Architecting the Domain Layer with 5+ hours of video, and a 160+ page study guide. See the concepts of this series IN ACTION!
Bob kicks off this series with an overview of what’s to come and his general approach towards researching and presenting the material.
In this video Bob wrestles with the definition, aim and goals of application architecture. He consults the giants like Martin Fowler, Robert Martin and many more to help come to terms with what architecture is and what it isn’t.
In this lesson, Bob describes the Software Development Lifecycle and how it correlates with the timing of architecture. Furthermore, he describes the collaborative and iterative nature of architecting an application, and cautions against “Big Design Up Front”.
In this lesson we talk about change and the impact that it has on our application development efforts, both during development and throughout the entire lifespan of the software. We talk about the reasons for change, the danger of coupling in a system, and outline the principles that help us mitigate the impact of change in our applications. We focus on the principle called Separation of Concerns and introduce the Layered Architectural Pattern. Other concerns appear such as the Single Responsibility Principle, Don’t Repeat Yourself that should guide us at a high level to mitigate the impact of change.
In this lesson we dive deeper into the Layered Architectural Pattern first asking what is a layer? Then we look at the various layers that comprise the pattern and discuss how they contribute to creating a typical system.
We begin looking at the Domain Layer because it is the most crucial layer to the entire system. As we’ll learn, the Domain Layer is a model of the business, modeling the business rules, validations, processes and workflows. It is the layer where the business users and the developers share a vocabulary and Bob makes a case for why it should be where we start and primarily focus our development efforts.
Next we talk about the responsibilities of the Presentation Layer and its sub-layers. We talk about it’s dependency on the Domain Layer (and we’ll discuss this further in another lesson) and the type of logic required to present and deliver data from the Domain Layer.
Moving on, we talk about the responsibilities delegated to the Persistence Layer and related topics like its relationship with the Domain Layer, the Entity Framework, Relational Database Management Systems, implementing security and more.
When discussing the Domain Layer, we saw how the Microsoft Application Architecture Guide referenced a sub-layer called the Application Facade which I termed the Application Services Layer. This layer is an abstraction between the Domain and Presentation Layers providing chunky methods that orchestrate chatty finer-grained methods in the Domain Layer. This video talks about the purpose, the role and the implementation of this layer.
The last layer we’ll discuss is a Web Services layer — a means of exposing Domain Layer or Application Services Layer functionality to be callable over a network. This is made possible by a series of standards and technologies. We discuss the purpose, role and implementation of this layer.
When we delegate responsibilities to classes in various layers, we do so with the intent that some will interface with other layers. This video talks about the types of layer interactions, describing chatty, finer-grained methods and chunky, coarser-grained methods and how this impacts the design of your application.
Data must flow through the layers of an application. What to pass from one layer to the next is challenging … this video talks about creating a new concern in the application devoted to tailored classes that pass all the disparate data required by the caller.
In previous lessons we talked at a high level about using Dependency Injection to invert the direction of the dependencies away from the Domain Layer to a new abstraction. In this video I explain the thought process behind Dependency Injection and how it can be used to achieve Separation of Concerns, to decouple classes across layers and more.
Vital to any application are foundational concerns that cross all layers like exception handling, logging, validation, security, instrumentation and more. This video talks about how to introduce these cross-cutting concerns into your design without coupling your system to them.
Once you have made some high-level architectural decisions and have plotted a course, the next step is to test your design by tackling a river of the application’s functionality from end user to data base. Here you decide on packaging, assigning responsibilities and classes to projects, namespaces, and more. Once you’re finished, you have an example architecture that helps communicate to other team members the roadmap to build the remainder of the application.
In this final lesson, Bob recaps the major ideas presented in this series and provides a number of books to reference for more details.