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

Stitcher.io:
Laravel domains
Oct 16, 2018 @ 10:44:58

On the Sticher.io site there's a new tutorial posted where Brendt shares some thoughts about domain driven design and splitting codebases to make them more maintainable and logically separated.

In this post we'll look at a different approach of structuring large code bases into separate domains. The name "domain" is derived from the popular paradigm DDD, or also: domain driven design.

While many concepts in this post are inspired by DDD principles, they will not follow every rule set by the paradigm. In our context, "domain" can also be named "module". A "domain" simply refers to a category of related stuff, that's it.

The post then starts with a definition of what a "domain" is and how it relates to functionality in an application (a Laravel app in this case). He gives an example of restructuring the code into "domains" of functionality rather than thinking about their types (enums, rules, etc). He provides a new proposed directory structure for these domains including folders for Actions, Exceptions, Rules, Status and ValueObjects. He then walks through several of these categories and gives a bit more detail about what's inside and some of the functionality those files might contain.

tagged: domains laravel tutorial domaindrivendesign ddd restructure directory

Link: https://stitcher.io/blog/laravel-domains

php[architect] Podcast:
Episode #11 - Conference Speaking, Static Analysis & Domain-Driven Design
Jul 31, 2018 @ 11:53:35

The php[architect] podcast, hosted by Eric van Johnson and John Congdon, has posted their latest episode: Episode #11 with a different format that before.

After a summer holiday, Eric van Johnson and John Congdon return with a new format.

Topics in this episode include:

  • conference speaking
  • static analysis with external services
  • code quality and compliance tests
  • domain driven architecture

Eric and John are also joined by guests Oscar Merida and Barney Hanlon to chime in on these topics. You can listen to this latest episode either through the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed for updates when future shows are released.

tagged: phparchitect podcast ep11 conference speaking staticanalysis domaindrivendesign

Link: https://www.phparch.com/podcast/episode-11/

Matthias Noback:
Doctrine ORM and DDD aggregates
Jun 25, 2018 @ 09:10:50

Matthias Noback has a post to his site today covering the use of Doctrine with domain-driven design as it relates to the definition and creation of the entities in your system.

As I discovered recently, you don't need an edge case to drop Doctrine ORM altogether. But since there are lots of projects using Doctrine ORM, with developers working on them who would like to apply DDD patterns to it, I realized there is probably an audience for a few practical suggestions on storing aggregates (entities and value objects) with Doctrine ORM.

He starts the article off by making a recommendation when building out your domain and entities: don't build with the ORM in mind. Its easy to think that entities and ORM models are the same thing, but he recommends defining them first and then figuring out how to work them in to the model structure. Eventually storing them and their state will have to be considered but that shouldn't influence the design. He illustrates with simple Line and PurchaseOrder entities and how to modify the base classes so they can be managed by Doctrine. He also covers some of the other concerns of making the transition over from entities to models in Doctrine (constraints, custom DBAL types, etc). He finishes the post covering annotations, the "one transaction only" DDD idea and value objects.

tagged: doctrine orm domaindrivendesign ddd tutorial database entity persistence

Link: https://matthiasnoback.nl/2018/06/doctrine-orm-and-ddd-aggregates/

Pehapkari.cz:
Domain-Driven Design, part 8 - Services and Factories
Mar 29, 2018 @ 10:09:28

The Pehapkari.cz blog has posted the latest article in their "Domain-Driven Design" series of posts covering the focus on the "domain" when developing an application rather than just features. In this latest tutorial, they cover services and factories to help with the encapsulation of functionality...and why they shouldn't be used.

This article is a reaction to readers’ confusion about services. We'll cover a domain service and domain factory in this article and when to use them and when not to.

Domain-driven design is about the domain. Domain services and domain factories do not exist in the domain. In general, we shouldn't use them. They are artificial constructions and this causes a lot of problems with code understanding, maintainability and also a divergence between the domain, the model, and the code.

The article continues the use of the e-commerce example when talking about the ideas of services and factories in the domain. It provides some basic examples (flow diagrams included) and the reasoning why they should not be used and what they could be replaced with.

tagged: domaindrivendesign domain service factory introduction avoid tutorial

Link: https://pehapkari.cz/blog/2018/03/28/domain-driven-design-services-factories/

Pehapkari.cz:
Domain-Driven Design - Alternative Relational Database Mapping
Mar 21, 2018 @ 10:37:16

The Pehapkari.cz blog has continued their series covering domain-driven design with the latest post in the series showing some alternative relational database mapping techniques.

Do you think that multilingual text must always be in a separate database table? Than this article is for you!

We will show that not all arrays have to be mapped as database tables. And we will also show the Doctrine implementation.

The article starts with a bit of background on what they're trying to accomplish: adding internationalization functionality to an e-commerce application. In order to make it simpler to work with the multi-language requirements they show the abstraction of its handling out into a LangValue value object that's used to store the product name value for each language. They then use this and some JSON encoded data to store the different language strings in the database directly with the product record rather than a different table. It then shows how to create the matching Doctrine entity for the LangValueType to work with the serialized column data and extract data from it's JSON blob.

tagged: domaindrivendesign series part4 relational database mapping internationalization doctrine

Link: https://pehapkari.cz/blog/2018/03/21/domain-driven-design-alternative-mapping/

Pehapkari.cz:
Domain-Driven Design - Repository
Mar 02, 2018 @ 11:46:25

The Pehapkari.cz site has continued their series on domain-driven design with their latest tutorial covering the use of a repository for handling instances and collections of objects.

We will discuss how to store and read domain objects while pretending we have an in-memory system. Simply, we will show how to implement and test repository.

The article starts with a look at collections and the reality of using them outside of an in-memory environment. It then focuses in on the idea of a repository that live in the domain layer and some of the responsibilities they have as a part of the overall system. With the basics defined the tutorial then gets into the concrete implementation of the repository and how to write effective tests to ensure its correct functionality.

tagged: domaindrivendesign series part3 repository tutorial

Link: https://pehapkari.cz/blog/2018/02/28/domain-driven-design-repository/

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/

Stefan Koopmanschap:
A rant about best practices
Jan 10, 2018 @ 13:19:02

Stefan Koopmanschap has shared a rant about best practices in a new post to his site. In it he shares some of his thoughts as presented in a lightning talk at the PHPAmersfoort meetup.

I have yet to talk to a developer that has told me that they were purposefully writing bad software. I think this is something that is part of being a developer, that you write software that is as good as you can possibly make it within the constraints that you have.

In our effort to write the Best Software Ever (TM) we read up on all the programming best practices: design patterns, refactoring and rewriting code, new concepts such as Domain-Driven Design and CQRS, all the latest frameworks and of course we test our code until we have a decent code coverage and we sit together with our teammates to do pair programming. And that's great. It is. But it isn't.

In the post he touches on a few main topics with his ideas for each:

  • Test Coverage
  • Domain-driven design
  • Frameworks
  • Event sourcing + CQRS
  • Pair programming
  • Refactoring + Rewriting

He ends the post with a suggestion to "consider all the best practices" when writing your code and developing applications. It's not just about applying them because they're defined as "best practices", it's about determining which of these practices make sense for your situation.

tagged: bestpractice rant opinion testing domaindrivendesign frameworks cqrs pairprogramming refactoring

Link: https://leftontheweb.com/blog/2018/01/10/A-Rant-About-Best-Practices/

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/

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/