Matthias Noback - Advanced Web Application Architecture

Advanced Web Application Architecture

Matthias Noback

2020 Matthias Noback

ISBN 978-90-821201-6-5

Cover drawings by Julia Noback

Other books by Matthias Noback:

• A Year with Symfony (Leanpub, 2014)
• Principles of Package Design (Apress, 2018)
• Microservices for Everyone (Leanpub, 2018)
• Object Design Style Guide (Manning Publications, 2019)
• PHP for the Web (Leanpub, 2020)

In memory of my grandfather, H.A.J. Noback

My last book, the Object Design Style Guide , ends with chapter 10 - A field guide to objects,showing the characteristics of some common types of objects like controllers , entities , value objects , repositories , event subscribers , etc. The chapter finishes with an overview of how thesedifferent types of objects find their natural place in a set of architectural layers. Some readerspointed out that the field guide itself was not detailed enough to help them use these types ofobjects in their own projects. And some people objected that the architectural concepts brieflydescribed in this chapter could not easily be applied to real-world projects either. They aretotally right; that last chapter turned out to be more of a teaser than a treatise. UnfortunatelyI couldnt think of an alternative resource that I could provide to those readers. Thereare some good articles and books on this topic, but they cover only some of thepatterns and architectural concepts. As far as I know, there is no comprehensive guideabout all of these patterns combined. So I decided to write it myself: a showcase ofdesign patterns, like entities and application services, explaining how they all worktogether in a well-architected application. However, a plain description of existingpatterns isnt nearly as useful as showing how you could have invented them byyourself, simply by trying to decouple your application code from its surroundinginfrastructure. Thats how this book became a guide to decoupling your domainmodel and your applications use cases from the framework, the database, and soon.

Separating infrastructure concerns from your core application logic leads to a domain modelthat can be developed in a domain-driven way. It also leads to application codethat is very easy to test, and to develop in a test-driven way. Finally, tests tendto be more stable and run faster than your average framework-inspired functionaltest.

Supporting both Domain-Driven Design (DDD) and Test-Driven Development (TDD) isalready a great attribute of any software system. But separating infrastructure fromdomain concerns by applying these design patterns gives you two more advantages.Without a lot of extra work you can start using a standard set of layers (whichwell call Domain , Application , and Infrastructure ). On top of that, you can easilymark your decoupled use cases as Ports and the supporting implementation code as Adapters .

Using layers, ports, and adapters is a great way of standardizing your high-level architecture, making it easier for everybody to understand the code, to take care of it, and to continuedeveloping it. And the big surprise that Ill spoil to you now is that by decoupling core codefrom infrastructure code you get all of this for free.

If your application is supposed to live longer than, say, two years, then decoupling frominfrastructure is a safe bet. Surrounding infrastructure like frameworks, remote web services,storage systems, etc. are likely to change at a different rate than your domain model and usecases. Whatever happens in the world of the technology surrounding your application, yourprecious core code wont be disturbed by it. Both can evolve at their own speed. Upgrading tothe next version of your framework, migrating to a different storage backend, or switching to adifferent payment provider wont cost as much as it would if core and infrastructure codewere still mixed together. Dependencies on external code or systems will always beisolated and if a change has to be made, youll know immediately where to makeit.

If on the other hand your application is not supposed to live longer than two years, that mightbe a good reason not to care about the approach presented in this book. That said, I have onlyseen such an application once or twice in my life.

This book is for you:

• If you have some experience with framework-inspired development, that is, following a frameworks documentation to structure a web application, or
• If you have seen some legacy code, with every part of the code base knowing about every other part, and different concerns being completely mixed together, or
• If youve seen both, which is quite likely since these things are often related.

I imagine youre reading this book because youre looking for better ways to structure thingsand escape the mess that a software project inevitably becomes. Heres my theory: softwarealways becomes a mess, even if you follow all the known best practices for softwaredesign. But Im convinced that if you follow the practices explained in this bookit will take more time to become a mess, and this is already a huge competitiveadvantage.

This book is divided into three parts. In Part (Decoupling from infrastructure) we look atdifferent code samples from a legacy application where core and infrastructure code are mixedtogether. We find out how to:

• Extract a domain model from code that mixes SQL queries with business decisions (Chapter )
• Extract a reusable application service from a controller that mixes form handling, business logic, and database queries (Chapter ).
• Separate a read model from its underlying data storage (Chapter )
• Rewrite classes that use service location to classes that rely on dependency injection (Chapter )
• Separate what we need from external services from how we get it (Chapter )
• Work with current time and random data independently from how the running application will retrieve this information (Chapter )

Along the way we find out the common refactoring techniques for separating these concerns.We notice how these refactoring techniques result in possibly already familiar designpatterns, like entities, value objects, and application services. We finish this part withan elaborate discussion of validation, and where and how it should or can happen(Chapter ).