Containerize dev, tst and prd

This post is part of The Containerization Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

After cleaning up the Symfony demo project a bit, we are ready to do some containerization…

I will talk about:

  1. Logging
  2. Containerizing dev, tst, and prd
  3. Run and stop the containers
  4. Remove database from VCS
  5. Integrate with PHPStorm

If you want to jump right into the code, this is the tag on GitHub.

Continue reading “Containerize dev, tst and prd”

Advertisements

Cleaning up the demo project

This post is part of The Containerisation Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

In order to start making experiments with containerization of applications, I am going to be using the Symfony demo project, which is a small blog where one can view and create some blog posts. Although it is a very small project, and therefore does not reflect the complexity of an enterprise cloud application, I feel it is flexible enough to experiment containerization practices, especially because I want to start small.

However, there are some things I don’t like about the project, so I start by doing some cleanup:

  1. Add roave/security-advisories
  2. Remove simple-phpunit, update to phpunit 7 and DAMA bundle 5
  3. Disable the profiler during test runs, so the tests run a bit faster
  4. Type hint all the things
  5. Change namespace from `App` to `Acme\App` to better comply with PSR-4
  6. Add a Makefile so we abstract our DevEx and automation from the tools

If you want to jump right into the code, this is the tag on GitHub.

Continue reading “Cleaning up the demo project”

The Containerization Chronicles

While working on the 18th post of The Software Architecture Chronicles, which is about implementing a proof of concept, I picked up the Symfony demo app and started refactoring away…

I started by cleaning up the project a bit and adding some functionality I like to have for better DevEx (development experience), but after some 20 commits I got annoyed with it and decided to try to get the environment as best as I could.

More or less at the same time, at work, we are currently moving to containers, and Kubernetes, and this would be a nice project to start diving into that.

So here it is, “The Containerization Chronicles”, a series of posts where I will be describing my experiments and learnings about the containers world.

I will be using the same repository as I will use for The Software Architecture Chronicles, so you will be able to access all the code there.

Posts in The Containerization Chronicles:

  1. The Containerization Chronicles
  2. Cleaning up the demo project
  3. Containerize dev, tst and prd
  4. Integrate with Scrutinizer CI
  5. Integrate with CodeCov
  6. Integrate with Heroku
  7. Add an Nginx container
  8. Replace the Nginx container for httpd
  9. Replace the httpd container for httpd+mod_php
  10. Make a benchmark on the previous 3 configurations
  11. Add a persistence container
  12. Start diving into Kubernetes… No idea what I’m gonna do here…

Just created hgraca/doctrine-test-db-regeneration-bundle

While working on the next post of The Software Architecture Chronicles I ended up creating a little symfony bundle which I called hgraca/doctrine-test-db-regeneration-bundle to generate and regenerate the tests database used by a phpunit tests suite.

It is inspired by some code that Luis Cobucci wrote back in 2017, and it uses the Doctrine fixtures to generate a backup of the tests DB, which is then put in place just before every test method and removed just after every test method.

It has 3 options:

  1. We can opt to use an existing tests DB backup, if it is available. This saves us the time to generate the DB, but it will not be useful if we want to test queries that are based on time like “select all users created in the last hour” because if the backup is older than 1h our tests will fail;
  2. We can opt to not put in place a new copy of the DB at the beginning of a test method, so that we can safely use the DAMA\DoctrineTestBundle together with this bundle;
  3. We can opt to not remove the DB at the end of a test method, so that we can safely use the DAMA\DoctrineTestBundle together with this bundle.

You can check out the bundle here: hgraca/doctrine-test-db-regeneration-bundle

Hope it’s useful for more people and constructive feedback is always welcome.

DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

After graduating from University I followed a career as a high school teacher until a few years ago I decided to drop it and become a full-time software developer.

From then on, I have always felt like I need to recover the “lost” time and learn as much as possible, as fast as possible. So I have become a bit of an addict in experimenting, reading and writing, with a special focus on software design and architecture. That’s why I write these posts, to help me learn.

In my last posts, I’ve been writing about many of the concepts and principles that I’ve learned and a bit about how I reason about them. But I see these as just pieces of big a puzzle.

Today’s post is about how I fit all of these pieces together and, as it seems I should give it a name, I call it Explicit Architecture. Furthermore, these concepts have all “passed their battle trials” and are used in production code on highly demanding platforms. One is a SaaS e-com platform with thousands of web-shops worldwide, another one is a marketplace, live in 2 countries with a message bus that handles over 20 million messages per month.

Continue reading “DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together”

Service Oriented Architecture (SOA)

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

The SOA Style has been around since the late 1980s and has its origins in ideas introduced by CORBA, DCOM, DCE and others. Much has been said about SOA, and there are a few different implementation patterns but, in essence, SOA focuses on only a few concepts and doesn’t give any prescription on how to implement them:

  • Composability of user-facing applications;
  • Reusable Business Services;
  • Technology stack independent;
  • Autonomy (independent evolution, scalability & deployability).

SOA is a set of architectural principles independent of any technology or product, just like polymorphism and encapsulation are.

In this post I am going to address the following patterns related to SOA:

Continue reading “Service Oriented Architecture (SOA)”

From CQS to CQRS

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

When we have an application that is data-centric, ie. implements only basic CRUD operations and leaves the business process (ie. what data to change and in what order) to the user, we have the advantage that the users can change the business process without the need to change the application. In the other hand, this implies that all users need to know all details of all business processes that can be performed using the application, which is a big problem when we have non-trivial processes and a lot of people that need to know them.

In a data-centric application, the application has no knowledge of the business processes, so the domain is unable to have any verbs, and is unable to do anything else aside from changing raw data. It becomes a glorified abstraction of the data model. The processes exist only in the heads of the application users, or even in post-its pinned to the computer screen.

A non-trivial, and really useful, application aims to remove the “process” burden from the user’s shoulders by capturing their intentions, making it an application capable of processing behaviours as opposed to simply storing data.

CQRS is the result of an evolution of several technical concepts that work together to help provide the application with an accurate reflection of the domain, while overcoming common technical limitations. Continue reading “From CQS to CQRS”