In a new post to his site Tomas Votruba shares his opinions on project structure and when he sees it appropriate to use a "monorepo" and when to use packages to compose your application.

Recently I gave a few talks about monorepo in PHP and how to integrate it to companies in a useful way. I'm very happy to see many people already use it and know what problems it solves.

Before monorepo hype takes over private PHP projects, I think you should know about its limits: When is the best time for you to go monorepo? When you gain less complexity while integrating it? How can you make the transition better? Is it really needed?

He starts off by describing some of the most common application structures including the monorepo, many-repository, and local package approaches. He sees each as an evolution on the previous and shares when he thinks the evolution makes the most sense (hint: it's about value). He ends the post by sharing a few final thoughts about monorepos and when they make sense for private projects versus public, open source projects.

Loïc Faugeron has posted the latest part of his "Mars Rover" series documenting the creation of a system to control a rover following the ideas of Monolithic Repositories, Command / Query Responsibility Segregation, Event Sourcing and Test Driven Development (using phpspec). In his previous posts he set up the project and created the package for navigation. in this latest post he gets into the navigation package.

Previously we've created a navigation package, we can now start developing the first use case:

Mars Rovers need first to be landed at a given position. A position is composed of coordinates (x and y, which are both integers) and an orientation (a string being one of north, east, west or south).

He starts off with using the Command Bus pattern to create a command, a handler and a bus that acts on the commands given. True to TDD he starts with the tests and fills in the code to make it all work. This generates the skeleton class for the test which is then filled in with functionality. Running the tests again then has them all passing once a few more changes are made to the internal handling (besides just the basics).

Loïc Faugeron has posted the next part of his "Mars Rover" series with the initialization of the project and taking some first steps with modules.

In this series we're going to build the software of a Mars Rover, according to the following specifications. It will allow us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES), Test Driven Development (TDD)

But first, we need to initialize our project.

He walks through the creation of the initial repository with a composer.json configuration and commits the initial version. From there he creates the "navigation" package that will handle write-only and read-only functionality to "drive" the rover around. He creates this package and a matching phpspec configuration file for testing the codebase. He then adds the navigation package to the main project though a branch merge.

Loïc Faugeron has started off a new series of posts with an introduction to a "Mars Rover" exercise that aims to help you refactor a "monolithic" codebase with CQRS, event sourcing and TDD practices.

In this introductory article, we're simply going to describe our Mars Rover specifications.

Note: This programming exercise originally comes from Dallas Hack Club, which is now unfortunately down. This Mars Rover kata has been adapted for the needs of this series.

He starts by outlining the goals the software will need to achieve and the complete functionality to provide. This is just the series kickoff though, so there's not much by way of code. Next in the series is the "MonoRepo" section and the setup of the actual project.