En el mundo del software, cuando se piensa en la arquitectura, no hay una definición concreta sino una serie de debates y opiniones al respecto. Todas y cada una de ellas objetables.
Por ejemplo, podemos pensar a la arquitectura como la organización fundamental de un sistema, es decir, los aspectos más importantes del diseño interno de un sistema de software, cómo están conectados los componentes de más alto nivel. Pero, ¿cómo se define qué es fundamental o de alto nivel?
También podríamos pensar que la arquitectura son las decisiones que deben ser tomadas al comienzo de un proyecto aunque, en realidad, son las decisiones que uno desearía haber tomado bien al inicio de un proyecto
Tell don’t ask es un principio de la programación orientada a objetos que nos ayuda a recordar que este paradigma se trata de crear objetos con lógica que operen con sus datos. Para clarificarlo, en vez de preguntarle datos a un objeto y actuar en consecuencia con esos datos, debemos decirle al objeto que hacer ya que él conoce sus datos.
TDD es una técnica de diseño de software que propone empezar por los test y que el diseño vaya surgiendo de ellos. Divulgada por Kent Beck, Robert Martin, Martin Fowler, etc. aunque con distintas escuelas entre ellos pero todos coinciden en los principales lineamientos. TDD se encuentra enmarcado dentro de las técnicas sugeridas por Extreme Programming en su apartado de pruebas automatizadas.
Los eventos de dominio (Domain Events) son uno de los patrones de diseño tácticos de Domain Driven Design (DDD).
Aparecieron posteriormente al libro azul donde Eric Evans introduce los conceptos fundamentales y tuvieron un gran impacto en la comunidad por las posibilidades que otorgan.
Desde la parte estratégica de DDD, se descubrió que para entender el problema de dominio era muy útil focalizarse en los principales eventos que ocurren en el negocio (como por ejemplo que un cliente hizo una compra o que un producto está listo para despachar).
Los eventos son grandes ordenadores de los procesos de negocio y permiten descubrir y entender flujos complejos que involucran a distintos actores.
Este principio establece que una entidad (clase, módulo, función, etc) debe quedar abierta para su extensión pero cerrada para su modificación. Debemos ser capaces de extender el comportamiento de nuestras entidades, sin necesidad de modificar su código.
