Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Matthieu Napoli:
Organizing code into domain modules
Dec 11, 2017 @ 12:57:01

In a post to his site Matthieu Napoli shares some recommendations about how to organize the code in your application using a "domain modules" approach. This is an organization method that relates the code based on functionality it relates to rather than the type of object it is.

We recently discussed 2 topics seemingly unrelated with my colleagues at Wizaplace: how to organize code [and] how to organize teams.

Regarding “how to organize teams”, we were discussing Spotify’s Feature teams. In a “classic” organization, teams are usually formed by grouping people based on their job title. [...] But in a “feature team” organization, teams are organized… by features. [...] The pros of this kind of organization are numerous and I do not intend to go over them here. But what does this have to do with code organization?

He starts with the "classic" code structure - organized by each item's type (ex: Entity, Service, etc). He then suggests reorganizing it move by what it does in the application, namely which module it belongs in best. He briefly touches on dependencies, "agile design" and the differences between a normal "product" and a "product" in e-commerce. He then applies these ideas and shares a domain organized directory structure, trying to reduce the overall complexity of the structure and the overall cohesion of the codebase.

tagged: domain module organization code directory structure tutorial

Link: http://mnapoli.fr/organizing-code-into-domain-modules/

Joey Masip Romeu:
Namespaces and organizing business logic services in Symfony
Dec 08, 2017 @ 11:04:35

In a post on his Medium site Joey Masip Romeu shares some suggestions about how you can organize your business logic in a Symfony application with some simple namespacing and service definitions.

I want to talk about namespacing services in Symfony, specifically Symfony3.

These are exciting times, Symfony 4 is just round the corner?— -coming out on November 30th? - ?so this blog post might be irrelevant soon! Nevertheless, concepts are still the same so let´s get into it!

He offers three "rules" that he and his team at SlowCode have defined to help with their own organization:

  • using a folder for logic services
  • using a folder for the domain name
  • using . for folder separation and _ for word separation

Code and configuration examples are provided for each suggestion helping to illustrate the point. He ends the post mentioning public and private services and how they're changing in upcoming Symfony releases.

tagged: namespace organize business logic symfony rule domain

Link: https://medium.com/@joeymasip/namespaces-and-organizing-business-logic-services-in-symfony-d80452adc4f7

Pehapkari.cz:
Domain-Driven Design - Language
Dec 08, 2017 @ 09:46:34

On the Pehapkari.cz blog today they've posted an article about something that, while not directly related to the code of your application, can help to improve the end result: defining a common language for domain-driven design.

Domain-driven design is a software design that focuses on understanding underlying business. It is useful for long-term projects because it leads to high-quality software that serves users. It helps when dealing with difficult problems, keeps track of core problems and prevents us from getting lost in the code.

The author starts the article by talking about issues before adopting a domain-driven design process and briefly describes what DDD is and what its goals are. The post then gets into some the basics behind defining your own domain and gives an example of definition of "account" and "price" for an e-commerce application. It then goes on to talk about goal of creating a ubiquitous language for the product that also includes functionality and process, not just the objects in the system.

tagged: domaindrivendesign domain language ubiquitous introduction

Link: https://pehapkari.cz/blog/2017/12/05/domain-driven-design-language/

Paul Jones:
Domain Logic and Email Templates
Jul 18, 2017 @ 11:59:50

Paul Jones has a new post on his site sharing some of his thoughts about the placement of domain logic and email templates in an ADR (Action/Domain/Responder) structure. The post is an answer to a recent question he received asking how to organize emails being sent by service classes.

In a way, sending an email as part of a web request/response cycle is like sending two responses: the normal HTTP response, and the email response. With that in mind, it might make sense to think of the HTML + Text email templates as part of a presentation layer. Or, as a combination of infrastructure (the email-sending client) plus presentation (the templates). That would be how to think about the separation of concerns there.

He then provides what he sees as a good directory structure to help keep it all separated out. He also talks about the load sending emails can put on a system, when to move it to workers and how that impacts where the templating of the emails should be done.

tagged: domain logic email template adr actiondomainresponder designpattern structure

Link: http://paul-m-jones.com/archives/6619

Paul Jones:
Controllers and Domain Exceptions
May 24, 2017 @ 09:19:52

In a new post to his site Paul Jones shares a conversation he had about handling domain exceptions in controllers and if it was a good practice or not.

A few months ago I had a great email conversation with a correspondent about how to handle business logic exceptions in his controller code. [...] If you find yourself in this situation, the first question to ask yourself is, “Why am I handling domain exceptions in my user interface code?” (Remember: Model-View-Controller and Action-Domain-Responder are user interface patterns; in this case, the user interface is composed of an HTTP request and response.) Domain exceptions should be handled by the domain logic in a domain-appropriate fashion.

He shares the original email (shortened) where they asked their question and outlined their current situation and setup. He points out that the point the other person made about not feeling right to thrown domain exceptions and having the controller handle them is a good path to follow but to take it even further. He suggests modifying the response to the domain logic to be a "domain payload" instead of an exception and then have the controller use that (getting its status) to determine how to proceed. This can prevent the need to catch random exceptions and provides more consistency to the overall flow.

tagged: domain exception controller payload question return tutorial

Link: http://paul-m-jones.com/archives/6608

TutsPlus.com:
Building Your Startup: Running Multiple Domains
Mar 17, 2017 @ 10:53:11

The TutsPlus.com site has posted their latest tutorial in their "Building Your Startup" series today. In this new article they show you how to update the application to support multiple domains in one Yii2 application.

The Yii2 advanced template allows you to run a number of sites in one code tree. I used its front-end tree to build Meeting Planner and its back-end tree to build the administrative suite of tools for the service. Today, however, I'll focus on launching another domain on top of the existing front-end tree—and all the small and large complexities that go along with this.

[...] I presumed it would be fairly simple (no pun intended) to launch Simple Planner, but it ended up taking a few days of work.

He points out that the work to get the frontend of the application working with a different domain name was relatively simple. It was the update to the email handling that took the most time (the application is very email-driven). He then shows the configuration changes required to add multiple domains, how to change the homepage for each domain and update images/links/etc to match the new domain. He then moves on to configuring the services used for each domain and, finally, the pieces that need to be updated to have the emails support the multiple domains.

tagged: startup build tutorial series yii2 multiple domain

Link: https://code.tutsplus.com/tutorials/building-your-startup-running-multiple-domains--cms-27459

Nikola Poša:
On structuring PHP projects
Jan 17, 2017 @ 10:17:18

Nikola Poša has shared some advice form his own experience on structuring PHP projects and some alternatives to some of the typical structures seen across many packages and applications.

An indispensable part of every programming project is how you structure it, which involves organizing files and sources into directories, naming conventions, and similar. As your application grows, so does the need for structuring it in way that it is easy to manage and maintain.

In most cases, structure of an average PHP-based application is dictated or influenced by the framework that is being used, which is something I'm opposed to. With no intention to be intrusive and without any bias towards specific framework, I'll share with you how I think about organizing my PHP projects.

He starts with a common directory structure seen in a wide range of projects in a framework agnostic way. He mentions the PHP-PDS project that tries to promote this same structure but also provides some alternatives:

  • grouping by archetype
  • grouping by feature
  • splitting out domain and general-purpose code

For each he provides an example of the directory structure and explains the rationale behind it a bit.

tagged: project structure applications grouping archetype feature domain

Link: http://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/

Paul Jones:
Command Bus and Action-Domain-Responder
Mar 10, 2016 @ 10:53:47

In this post to his site Paul Jones looks at the combination of the Action-Domain-Responder pattern and the Command Bus pattern in application development. In the post he answer the question about how they fit together.

Over the past few weeks, different people have asked me where a Command Bus goes in an Action-Domain-Responder system. While I’m not a DDD expert, after brushing up on the subject a little, my answer is: "In the Domain."

He starts by reviewing the three pieces of the ADR pattern with brief descriptions of each. The then covers the Command Bus pattern, linking to several other resources with more details about the pattern itself and a quick summary of their main points. He talks about how the overall structure is a part of the Command Query Responsibility Segregation pattern and suggests that, since the Command Bus pattern is a "fire and forget" kind of thing it belongs in the Domain of ADR. He gives a brief code example and answers other questions about validation and error handling as a part of this suggested flow.

tagged: action domain responder adr commandbus architecture suggestion

Link: http://paul-m-jones.com/archives/6268

Ewan Valentine:
Designing Domain Specific Language
Sep 25, 2015 @ 11:56:54

In a post to his site Ewan Valentine looks at some considerations to think about when creating a domain specific language in your applications. This kind of language helps define common terms, conventions and practices for developers to follow in their code.

When you spin up a framework such as Laravel, Symfony etc. The first thing you'll notice, is that they have their own 'feel'. I often joke that Symfony2 is like Java and Laravel is like Ruby.

But what gives an application or a framework a 'feel'? Domain specific language or 'DSL'. Domain specific language is almost like a syntax or a language specific to your application and ecosystem. DSL is what makes your applications code unique and more usable.

He gives a specific example of a Laravel application he was creating and how he wanted the interface to function, transforming the result of a find() into a JSON response. He shows how it could actually be done but that introduces more maintenance and more code to cover. Instead he worked backwards into the domain context the request was operating in and found an ideal injection point for transformation that would keep it out of the controller action itself.

So, to design usable domain specific syntax, start at the front. In other words the part you'll be writing the most, and then work backwards to abstract the logic and make it actually work.
tagged: domain specific language design laravel injection transform json

Link: http://ewanvalentine.io/designing-domain-specific-language/

Paul Jones:
Service Classes, Payloads, and Responders
Aug 12, 2015 @ 10:52:27

Paul Jones has written up a post talking about service classes, payloads and responders and how they can help pull logic out of controllers and into more reusable chunks. It's inspired by comments and methods mentioned in another earlier post from Revath Kumar.

Revath Kumar has a good blog post up about extracting domain logic from controllers and putting that logic in a service class. After reading it, I commented that with a little extra work, it would be easy to modify the example to something closer to the Action-Domain-Responder pattern. In doing so, we would get a better separation of concerns (especially in presentation).

Paul applies some of the concepts that Revath outlined to the ADR pattern, suggesting that service classes should always return Payloads and the reduction of functionality in the controller overall. He includes an example of what the resulting code would look like, following along with the "orders" scenario outlined in Revath's post.

tagged: service class payload responder adr action domain responder designpattern

Link: http://paul-m-jones.com/archives/6172