Monoliths are bad... are they?

Some things happened recently that made me write this post: First one, HEY was released. If you are not from this planet and never heard about HEY, you only need to know that it is a new and peculiar email service that made a bit of noise in social networks due to some issues with Apple. Anyway, the point is that David Heinemeier Hansson made some statements about its architecture on Twitter… he declared it was a monolithic application.

Domain-Driven Design: The cool parts (Part 2)

In the first part of this series we introduced the basic principles that serve as a core of the Domain-Driven Design: The ubiquitous language, the model and the layered architecture. In this post we’ll review a first bunch of components used to model the domain: Entities, Value Objects, Services, Modules and Aggregates. Entities and Value Objects An Entity is the most basic kind of component in the set of tools to model your domain, and basically it’s an object that represents something that has an unique identity, that is preserved over time and thorough different representations.

How to execute Jenkins jobs programatically

The most common usage of Jenkins is to trigger job builds automatically in response to changes in a source code repository. In some other cases you may need to trigger jobs because of any other reason. For example, imagine that you want to execute a Jenkins job after your alert management system detects something is wrong, so it can execute a pipeline that fixes everything and the alert is resolved. This is just an example, but the idea of this post is to be able to execute a Jenkins job programatically, and not using the GUI or anything related to Jenkins itself.

Domain-Driven Design: The cool parts (Part 1)

In this series of posts I’ll try to summarize and distill the great and famous book written by Eric Evans, "Domain-Driven Design: Tackling Complexity in the Heart of Software", by explaining the concepts that I liked the most in an easy and friendly way. Hopefully it will also help someone that is reading the book as well. In this first part I’ll focus on explaining the Domain-Driven Design mindset, which is the core that needs to be understood by the people who want to apply the principles in their daily basis, and start programming using this approach.