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

Pehapkari.cz:
Domain-Driven Design - Implementation
Feb 22, 2018 @ 10:15:35

The Pehapkari.cz blog has continued their series covering domain-driven design with their latest post. In this new article they focus on the implementation of the concepts they've been covering starting with the domain model.

It is great to model something and now we have reached the point where we turn the model into the code. We will implement the model, no persistence, no input, only the most important part - the domain model. The implementation will be supported by tests and we will see how easy it is to test domain objects. We will also discuss the connection to the ubiquitous language and model and practical aspect of object encapsulation.

The tutorial then starts in covering the domain model structure and includes a few things to to think about during the implementation. It talks about reading values from the object and links to the full code on GitHub (rather than fill up the post with code). The post finishes by covering testing of the model, the idea of test-driven development and how it fits in with domain-driven design.

tagged: domaindrivendesign domain model implementation series part3

Link: https://pehapkari.cz/blog/2018/02/21/domain-driven-design-implementation/

Paul Jones:
Solving The “Widget Problem” In ADR
Jan 03, 2018 @ 12:54:43

Paul Jones has a post to his site covering a method he's worked up to solve the "widget" problem in ADR, the Action-Domain-Responder design pattern he worked on defining.

The “widget problem” is when you have several panels or content areas on an HTML page that have different data sources. You might have a main content area, then a calendar off to the side, with perhaps a list of recent news items or blog posts, a todo or reminder widget, and maybe other information panels. The problem is that they each have different data sources, and may not always be displayed in every circumstance — perhaps they are only shown to some users based on their preferences, or under certain conditions.

So how, in Action-Domain-Responder, do we get the “right” data for the set of widgets that are actually going to be displayed?

His answer is pretty simple, basically that the requests are handled the same as everything else but with more kinds of data contained in the "domain" of the response. He walks through a code example of a site that would pull out the set of widgets to show and inject them into the "payload" for passing back to the responder for output handling.

tagged: widget actiondomainresponder designpattern problem domain tutorial

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

Pehapkari.cz:
Domain-Driven Design - Model
Dec 18, 2017 @ 09:03:21

On the Pehapkari.cz blog they've continued their "Domain-Driven Design" series with the latest post focusing on models.

All of us model every day. A friend tells us a joke, we imagine the situation and if we model it as is intended, we find the situation funny. A customer wants to have a new functionality and while he speaks, we try to imagine what does the customer wants - we model.

We are going to take a look at what is software modeling, how can we express the model and how can we capture key concepts.

The post starts off with an overview of what "modeling" is to get everyone on the same page. It also talks about validation of the model by domain experts and some questions to ask to ensure the model provides the right data. They include a more practical example of a shopping cart and some key concepts and constraints that might come along with it. Some illustrations are included in the post to help give a bit more visual context to the contents.

tagged: domaindrivendesign domain language model series part2

Link: https://pehapkari.cz/blog/2017/12/16/domain-driven-design-model/

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/