Domain-Driven Design: Domain Events and BC Integration Webcast at @AtrapaloEng (Spanish)
Siguiendo con la formación de DDD en Atrápalo, os dejo la sesión de formación sobre Domain Events y BC Integration. Que la disfrutéis.
Domain-Driven Design: Bounded Context Integration (Spanish)
Os dejo el video de la charla que impartí el pasado 25 de Octubre de 2014 en la Barcelona Software Craftsmanship.
Domain-Driven Design: Entities and Value Objects Webcast at @AtrapaloEng (Spanish)
Siguiendo con las formaciones de DDD de Atrápalo, os dejo el video sobre Entities y Value Objects.
Domain-Driven Design: Aggregates Webcast at @AtrapaloEng (Spanish)
En Atrápalo, estamos haciendo formación semanal sobre DDD. Estoy grabando todos los screencast y los iré publicando semana a semana. El primero sobre Strategical no lo pudimos grabar pero gran parte del contenido lo podéis encontrar en la sesión que grabé en la Monthly Talk en Octubre de 2014. A continuación, os dejo la sesión de formación sobre Aggregates, al final hay discusión sobre SOLID, especialmente SRP. Que la disfrutéis.
Tactical Domain-Driven Design Screencast at PHPBarcelona (Spanish)
Os dejo el video sobre DDD Tactical Design que hice en la Monthly Talk de PHPBarcelona. Nos dio tiempo a charlar un poco de estrategia, ver los Value Objects, Entities y algo de Repositories. La charla está basada en el libro que Christian, Keyvan y yo estamos escribiendo en leanpub: “Domain-Driven Design with PHP by Examples”. En los últimos 30 minutos hablo sobre cómo estamos gestionando la Integración Continua en Atrápalo.
Dogmáticos a favor vs. radicales en contra
Las herramientas y las metodologías no fallan, son las personas al aplicarlas. Una llave inglesa no puede fallar, o es la herramienta adecuada para tu problema o no lo es. Si eliges una llave inglesa para un trabajo que no es el suyo, el error es tuyo. No existe el legacy code, sólo los legacy teams, o las legacy companies que generan el legacy code.
En los proyectos Web veo dos tipos de proyectos en función del estado en el que se encuentran: los que especulan para ver si funcionan (start-ups, etc.) y los que han conseguido consolidarse y tienen una proyección a largo plazo. La gran mayoría son unos terceros, que son los que no tiran y se han de cerrar.
En los que especulan, la gran mayoría de veces, tiene todo el sentido el “don’t worry be crappy” si te ayuda a ir más rápido para poder mostrar que el proyecto funciona, ganas usuarios, emites algunas facturas, puedes conseguir financiación y tirar adelante. Si todo va bien, curras mucho, consigues funding y después de algún tiempo, el proyecto se consolidará. ¡Felicidades! Ahora bien, todo lo rápido que has ido al principio tocará hacerlo bien hecho para reducir los costes de mantenimiento (lanzamiento de nuevas funcionalidad, bugs, etc.) ya que tu proyecto ya no especula sino que ha venido para quedarse. Seguro que habéis visto las típicas gráficas de la deuda técnica.
En los proyectos consolidados, cualquier herramienta que acelere la velocidad de desarrollo reduciendo costes de mantenimiento es un plus. Las metodologías de desarrollo ayudan este objetivo. Cada uno es libre de usarlas o no.
Ellas son las verdades crafts(wo)men
“Hexagonal Architecture with PHP” was published in phparch|magazine
This week, the php|architect magazine has published an article of mine about “Hexagonal Architecture with PHP”. Here’s the introduction:
“With the rise of DDD (domain-driven development), architectures promoting domain-centric designs are becoming more popular. This is the case with Hexagonal Architecture, also known as Ports and Adapters, that seems to have been rediscovered recently by PHP developers. Invented in 2005 by Alistair Cockburn, one of the Agile Manifesto authors, the Hexagonal Architecture allows an application to be equally driven by users, programs, automated tests, or batch scripts, while being developed and tested in isolation from its eventual run-time devices and databases. This results in infrastructure-agnostic web applications that are easier to test, write, and maintain. Let’s see how to apply it using real PHP examples.”
I would like to share with you some thought, the cover and the code repository.
Legacy Code and Teams Series: Training Sessions and Technical Committee
(Next: Legacy Code and Teams Series: Composer)
When talking with some friends about how we are improving Atrápalo legacy code and development process, they asked for creating a presentation and give a talk about the steps we are following, hows, whys, and so on. It sound to me interesting so I would like to help sharing my experiences, not just the Atrápalo ones because when working at Emagister we did something quite similar with Christian, Eber, Dario, Lluís, Jordi, Jose Luís and the rest of the team with great results.
Before jumping into a talk, I would like to start a serie of posts about my way dealing with legacy projects. I’m really interested in listening from you and your comments in order to enrich the final result. So, any suggestion or experience is really welcomed.