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

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/

Jeroen de Dauw:
Implementing the Clean Architecture
Feb 21, 2017 @ 10:41:45

In a recent post to his site Jeroen de Dauw looks at some of his own work and ideas around implementing clean architecture in PHP-based applications. The idea behind "clean architecture" is a focus on separation of concerns and dividing the systems into "layers" with contained logic in each.

Both Domain Driven Design and architectures such as the Clean Architecture and Hexagonal are often talked about. It’s hard to go to a conference on software development and not run into one of these topics. However it can be challenging to find good real-world examples. In this blog post I’ll introduce you to an application following the Clean Architecture and incorporating a lot of DDD patterns. The focus is on the key concepts of the Clean Architecture, and the most important lessons we learned implementing it.

In his post he looks at a real-world application (the Wikimedia Deutschland fundraising software) and how Domain Driven Design plays into the "clean" structure. He then walks through code examples, directory structures and lessons learned along the way (including bounded contexts and effective validation).

tagged: clean architecture tutorial guide domaindrivendesign designpattern

Link: https://www.entropywins.wtf/blog/2016/11/24/implementing-the-clean-architecture/

SitePoint PHP Blog:
Event Sourcing in a Pinch
Nov 30, 2016 @ 10:56:26

Christopher Pitt is back with a new tutorial on the SitePoint PHP blog talking about event sourcing in PHP including a brief explanation about what it is and how it can be useful in your PHP application.

Let’s talk about Event Sourcing. Perhaps you’ve heard of it, but haven’t found the time to attend a conference talk or read one of the older, larger books which describe it. It’s one of those topics I wish I’d known about sooner, and today I’m going to describe it to you in a way that I understand it.

Christopher then gets into some of the basic concepts behind event sourcing, a part of Domain Driven Design, and the difference between storing state and storing behavior. With this outlined he gets into the creation of the actual event handlers with examples from a retail application (orders, outlets, stock, pricing, etc). He includes the code for several simple events, a method for recoding them in your database and some helper functions to translate the event to the SQL required for the insert operation. He then links these with the event classes and putting them to use, executing them and getting the results back via a sort of "layer" between the fetch and the response.

tagged: eventsourcing tutorial introduction example domaindrivendesign

Link: https://www.sitepoint.com/event-sourcing-in-a-pinch/

SitePoint PHP Blog:
Modeling an Aggregate with Eloquent
Nov 30, 2015 @ 11:49:19

The SitePoint PHP blog has a tutorial posted from Andrew Cairns showing you how to model an aggregate with Eloquent, the database access layer from the Laravel framework. The "aggregate" here is an implementation of the Aggregate design pattern, a system of smaller opbjects operating as a whole.

The Aggregate pattern is an important part of Domain Driven Design. It prevents inconsistencies and is responsible for enforcing business rules within a collection of objects. For these reasons alone, it is clear to see why it is a key component of a domain model.

[...] Mixing persistence concerns into a Domain Model can become complex and lead to a lot of bad decisions. This does not mean that it is impossible to create an Active Record Domain Model. In this article, we will work through an example of building an Aggregate which also extends Eloquent: a popular Active Record ORM.

They start with a brief summary of what the Aggregate design pattern, how its objects work together and the point of a "root" object. They help illustrate how it would in a more real-world situation with a simple blog system, starting with a simple Post object minus the Eloquent integration. From there they bring in Eloquent, showing how to extend it with the class and what features it introduces. Most of the changes they make then revolve around a "lock" on the post and where value objects and the invariant rule comes in to play.

tagged: aggregate eloquent designpattern domaindrivendesign tutorial

Link: http://www.sitepoint.com/modeling-aggregate-eloquent/