Advanced Web Application Architecture
Advanced Web Application Architecture
About the Book
Looking for a print edition? It's available on Lulu.
"A practical guide on providing you a breakthrough in your architectural skills to build web applications in an adaptive & sustainable manner." -- Mohammad Emran Hasan
Web applications deserve to outlive the currently fashionable framework. Your application's core use cases deserve to be decoupled from their surrounding infrastructure. And all of your domain-specific code needs to be testable; it has to be tested after all.
This book helps you get your web applications back in shape. It contains many techniques for decoupling from infrastructure (like the framework, the database, or remote web services). In Part 1 we unlock a collection of design patterns which help you establish a clean separation between core and infrastructure code. Part 2 shows how these design patterns resonate at a higher level with architectural concepts like layers, ports and adapters (a.k.a. Hexagonal architecture). The book finishes with a discussion of testing strategies and design trade-offs.
What you'll learn
- Separating mixed code into core and infrastructure code by refactoring into patterns
- Dividing your code into layers, and making a clear distinction between an application's ports and adapters
- Testing decoupled applications
Each chapter comes with exercises to test your understanding.
This is a book for experienced web developers. Code samples are written in PHP and are easy to follow by developers who write code in other OOP dialects, like C#, Java, etc.
"The best guide that brings your coding and architecture skills a level up. All the modern PHP features combined with the elegance of a well designed modular design." -- José María Valera Reales
There is an accompanying real-world project that showcases the design techniques and principles explained in this book. For a one-time fee you get access to this project, including any future updates. Subscribe at https://enjoy.gitstore.app/repositories/matthiasnoback/read-with-the-author.
"The author achieves what most others don't - making the core idea so simple that it is near impossible for the reader to get wrong. The only architecture book I would recommend even to my junior colleagues." -- Ondřej Bouda
About the Author
Packages
The Book
With this package you get a copy of the book, including any of its future updates.
PDF
EPUB
English
The Book: Team license
With this package you get 5 copies of the book, including any of its future updates.
PDF
EPUB
English
The Book: Enterprise license
With this package you get 10 copies of the book, including any of its future updates.
PDF
EPUB
English
Bundles that include this book
Table of Contents
- Introduction
- 1 Preface
- 2 Why is decoupling from infrastructure so important?
- 3 Who is this book for?
- 4 Overview of the contents
- 5 The accompanying demo project
- 6 About the author
- 7 Acknowledgements
- 8 Complementary e-book copy
- I Decoupling from infrastructure
- 1 Introduction
- 1.1 Rule no 1: No dependencies on external systems
- 1.2 Abstraction
- 1.3 Rule no 2: No special context needed
- 1.4 Summary
- Exercises
- 2 The domain model
- 2.1 SQL statements all over the place
- 2.2 Trying to fix it with a table data gateway
- 2.3 Designing an entity
- 2.4 Introducing a repository
- 2.5 Mapping entity data to table columns
- 2.5.1 Using an ORM
- 2.5.2 Manual mapping
- 2.6 Generating the identifier earlier
- 2.6.1 Using UUIDs instead of (auto-)incrementing integer IDs
- 2.7 Using a value object for the identifier
- 2.8 Active Record versus Data Mapper
- 2.9 Summary
- Exercises
- 3 Read models and view models
- 3.1 Reusing the write model
- 3.2 Creating a separate read model
- 3.3 Read model repository implementations
- 3.3.1 Sharing the underlying data source
- 3.3.2 Using write model domain events
- 3.4 Using value objects with internal read models
- 3.5 A specific type of read model: the view model
- 3.6 Using view models for APIs
- 3.7 Summary
- Exercises
- 4 Application services
- 4.1 Considering other infrastructures
- 4.2 Designing a use case to be reusable
- 4.3 Extracting an application service
- 4.4 Introducing a parameter object
- 4.5 Dealing with multiple steps
- 4.6 Summary
- Exercises
- 5 Service locators
- 5.1 From service location to explicit dependencies
- 5.2 Depending on global state
- 5.3 Injecting dependencies
- 5.4 Injecting configuration values
- 5.5 Using method arguments for job-specific data
- 5.6 Clients of reusable services
- 5.7 Testing
- 5.8 Effective testing
- 5.9 The Composition root is near the entry point
- 5.10 Summary
- Exercises
- 6 External services
- 6.1 Connecting to the external service
- 6.2 Introducing an abstraction
- 6.3 Architectural advantages
- 6.4 Testing
- 6.5 Summary
- Exercises
- 7 Time and randomness
- 7.1 Passing current time and random data as method arguments
- 7.2 Introducing factories
- 7.3 Introducing value objects
- 7.4 Improving the factories
- 7.5 Manipulating the current time
- 7.6 Integration tests again
- 7.7 Summary
- Exercises
- 8 Validation
- 8.1 Protecting entity state
- 8.2 Using value objects to validate separate values
- 8.3 Form validation
- 8.4 Using exceptions to talk to users
- 8.5 When validation is not the answer
- 8.6 Creating and validating command objects
- 8.7 Summary
- Exercises
- 9 Conclusion
- 9.1 Core code and infrastructure code
- 9.2 A summary of the strategy
- 9.2.1 Use dependency injection and inversion everywhere
- 9.2.2 Make use cases universally invokable
- 9.3 Focus on the domain
- 9.4 Focus on testability
- 9.5 Pure object-oriented code
- 9.6 Summary
- 1 Introduction
- II Organizing principles
- 10 Introduction
- 11 Key design patterns
- 11.1 Framework-inspired structural elements
- 11.2 Entities
- 11.2.1 Protect invariants
- 11.2.2 Constrain updates
- 11.2.3 Model state changes as actions with state transitions
- 11.2.4 Don't think too much about tables
- 11.2.5 Record domain events
- 11.3 Repositories
- 11.4 Application services
- 11.4.1 Return the identifier of a new entity
- 11.4.2 Input should be defined as primitive-type data
- 11.4.3 Wrap input inside command objects
- 11.4.4 Translate primitive input to domain objects
- 11.4.5 Add contextual information as extra arguments
- 11.4.6 Save only one entity per application service call
- 11.4.7 Move secondary tasks to a domain event subscriber
- 11.5 Event subscribers
- 11.5.1 Move subscribers to the module where they produce their effect
- 11.5.2 Delegate to an application service
- 11.6 Read models
- 11.6.1 Use internal read models when you need information
- 11.6.2 Choose a standard implementation for the repository
- 11.6.3 For view models, prepare the data for rendering
- 11.7 Process modelling
- 11.8 Summary
- 12 Architectural layers
- 12.1 MVC
- 12.2 A standard set of layers
- 12.2.1 The infrastructure layer
- 12.2.2 The application layer
- 12.2.3 The domain layer
- 12.2.4 Up and down the layer stack
- 12.3 The Dependency rule
- 12.4 Making layers tangible
- 12.4.1 Documenting the architecture
- 12.4.2 Using namespaces for layering
- 12.4.3 Automated verification of design decisions
- 12.5 Summary
- Exercises
- 13 Ports and adapters
- 13.1 Hexagonal architecture
- 13.2 Ports
- 13.3 Adapters for outgoing ports
- 13.4 Adapters for incoming ports
- 13.5 The application as an interface
- 13.6 Combining ports and adapters with layers
- 13.7 Structuring the Infrastructure layer
- 13.8 Summary
- Exercises
- 14 A testing strategy for decoupled applications
- 14.1 Unit tests
- 14.2 Adapter tests
- 14.3 Contract tests for outgoing port adapters
- 14.4 Driving tests for incoming port adapters
- 14.5 Use case tests
- 14.6 End-to-end tests
- 14.7 Development workflow
- 14.8 Summary
- Exercises
- 15 Conclusion
- 15.1 Is a decoupled architecture the right choice for all projects?
- 15.2 My application is not supposed to live longer than two years
- 15.3 My application offers only CRUD functionality
- 15.4 My application is a legacy application
- 15.5 I can never make my entire application decoupled
- 15.6 Isn't this over-engineering?
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.
You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!
So, there's no reason not to click the Add to Cart button, is there?
See full terms...
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $12 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
