Save Big on Coursera Plus. 7,000+ courses at $160 off. Limited Time Only!
An architect's job is to manage complexity, not increase it. Yet the developer life is filled with jargon, acronyms, and seemingly infinite choices. So how do we know when complexity makes sense? Viewers will learn when abstractions are justified and walk away with an understanding of the merits of various approaches for structuring the business, service, presentation and data access layers with a pragmatic, real-world mind set.
An architect's job is to manage complexity, not increase it. Yet the developer life is filled with jargon, acronyms, and seemingly infinite choices. So how do we know when complexity makes sense? This course discusses when abstractions are justified and outlines the merits of various approaches for structuring applications with a pragmatic, real-world mind set. The discussion begins by outlining philosophies for thinking about architecture and considering the benefits of doing the simplest thing that could possibly work. Then we dive into various design patterns and technologies to consider within the business, service, presentation and data access layers. And in the final capstone module we'll consider two specific architectures and discuss the contexts where each makes sense. You'll learn when table module, active record, DDD, and ORMs are useful and walk away with the tools to better evaluate and justify complexity as an agile software craftsman. Like any responsible architect, we'l focus on the value of keeping things simple whenever we can.
An architect's job is to manage complexity, not increase it. Yet the developer life is filled with jargon, acronyms, and seemingly infinite choices. So how do we know when complexity makes sense? This course discusses when abstractions are justified and outlines the merits of various approaches for structuring applications with a pragmatic, real-world mind set. The discussion begins by outlining philosophies for thinking about architecture and considering the benefits of doing the simplest thing that could possibly work. Then we dive into various design patterns and technologies to consider within the business, service, presentation and data access layers. And in the final capstone module we'll consider two specific architectures and discuss the contexts where each makes sense. You'll learn when table module, active record, DDD, and ORMs are useful and walk away with the tools to better evaluate and justify complexity as an agile software craftsman. Like any responsible architect, we'l focus on the value of keeping things simple whenever we can.