I wanted to share with you a free chapter from my latest book, "Advanced Web Application Architecture". I've picked Chapter 11, which gives a compact overview of all the design patterns that are useful for structuring your web application in a way that will (almost) automatically make it independent of surrounding infrastructure, including the web framework you use.

Chapter 11 is the first chapter of Part II of the book. In Part I we've been discovering these design patterns by refactoring different areas of a simple web application. Part II provides some higher-level concepts that can help you structure your application. Besides design patterns, it covers architectural layering, and hexagonal architecture (ports & adapters). It also includes a chapter on testing decoupled applications.

If you're interested in this kind of topic, make sure to get a discounted copy using this link: https://leanpub.com/web-application-architecture/c/RELEASE_DAY.

Chapter 11: Key design patterns

This chapter covers:

• A catalog of design patterns
• Implementation suggestions
• A high-level design process based on these design patterns

11.1 Framework-inspired structural elements

Every framework comes with its own set of recognized element types. For instance, Symfony developers learn to create controllers, entities, form types, Twig templates, Yaml configuration files, and so on. Laravel developers also create controllers, but they need among other things: models, Blade templates, and PHP configuration files. When you take a look at the directory structure of most web application projects, you'll immediately notice the framework that's been used. Frameworks dictate your project structure. And frameworks also invade your code. This all sounds like frameworks are an enemy, instead of the helpful friend they presume to be, but this is a false contradiction. In infrastructure code, frameworks are your friend. In core code, they are not.

If frameworks determine the structure of your core code, you'll end up with:

• Implicit use cases inside controllers,
• A domain model that's coupled to its underlying infrastructure, and in general
• Code that's coupled to the framework.

In Part I: Decoupling from infrastructure we've already seen many techniques to overcome these problems. We were able to extract a use case from a controller by modeling it as a framework-independent service. We extracted an entity from database interaction code. And we decoupled code from the framework by using dependency injection everywhere, and by passing contextual information as method arguments.

In this chapter we take a closer look at the types of objects that were the result of decoupling from infrastructure. Knowing more about the typical aspects of these objects will help you use them as building blocks instead of merely the result of refactoring activities. By using these objects as "primitives" you can implement all of the application's use cases, without even choosing a framework. The framework will just be the finishing touch, the bridge between your application's core and the outside world.

11.2 Entities

The first pattern to cover is the Entity pattern. In this book the concept of an entity is the same as the concept of an aggregate in Domain-Driven Design literature. An aggregate is an entity, including any of its child entities, and any of the value objects used inside of it. In my experience the term "aggregate" leads to a lot of confusion so I decided to use the word "entity" in this book. We have talked about entity design in Chapter 2: The domain model, and I've already mentioned several design rules for it there. Still, I want this chapter to be a reference guide to the standard design patterns you'll need in decoupled application development, so I'll briefly summarize the rules here. I'll just declare the rules without defending them in detail. You can always look up the reasoning in Eric Evans' "Domain-Driven Design - Tackling complexity in the heart of software", Addison-Wesley Professional (2003). A quick and accurate primer on the topic is Vaughn Vernon's article series "Effective Aggregate Design".

Entities are objects that preserve the state of your application. They are the only type of objects in your application that have persistent state. Most of the other objects should be designed to be immutable and stateless. Being mutable, entities should not be passed to clients that don't intend to change their state. When a client

Truncated by Planet PHP, read more at the original (another 46211 bytes)