Where should it go?

If you're one of those people who make a separation between an application and a domain layer in their code base (like I do), then a question you'll often have is: does this service go in the application or in the domain layer? It sometimes makes you wonder if the distinction between these layers is superficial after all. I'm not going to write again about what the layers mean, but here is how I decide if a service goes into Application or Domain:

Is it going to be used in the Infrastructure layer? Then it belongs in the Application layer.

This is an excerpt from my book PHP for the Web. It's a book for people who want to learn to build web applications with PHP. It doesn't focus on PHP programming, but shows how PHP can be used to serve dynamic web pages. HTTP requests and responses, forms, cookies, and sessions. Use it all to build a CRUD interface and an authentication system for your very first web application.

Chapter 11: Error handling

As soon as we started using a PHP server to serve .php scripts in Chapter 2 we had to worry about errors and showing them in the browser. I mentioned back then that you need to make a distinction between the website as it is still running on your own computer and the website as it is running on a publicly accessible server. You may find that people talk about this distinction in different ways. When you're working on your website on your own computer you're running it "locally" or on your "development server". When it runs on a publicly accessible server it has been "deployed" to the "production server". We use different words here because these are different contexts or environments and there will be some differences in server configuration and behavior of the website depending on whether it runs locally or on the production server. In this chapter we'll improve the way our website handles errors and we'll make this dependent on the environment in which the website runs.

As a rather unusual pastime for the Saturday night I attended the third Domain-Driven Design Africa online meetup. Thomas Pierrain a.k.a. use case driven spoke about his adaptation of Hexagonal architecture. "It's not by the book," as he said, but it solves a lot of the issues he encountered over the years. I'll try to summarize his approach here, but I recommend watching the full talk as well.