PHPackages forkrefactor/ddd - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Framework](/categories/framework) 4. / 5. forkrefactor/ddd ActiveLibrary[Framework](/categories/framework) forkrefactor/ddd ================ Mini Framework to create projects with hexagonal architecture and domain driven design v1.0.0(4y ago)01052MITPHPPHP ^8.1 Since Dec 8Pushed 4y ago1 watchersCompare [ Source](https://github.com/forkrefactor/ddd)[ Packagist](https://packagist.org/packages/forkrefactor/ddd)[ RSS](/packages/forkrefactor-ddd/feed)WikiDiscussions master Synced 1mo ago READMEChangelog (1)Dependencies (6)Versions (2)Used By (2) DDD Mini Framework. =================== [](#ddd-mini-framework) Pequeño framework para desarrollar aplicaciones mediante una arquitectura ES (event sourcing) + DDD (Domain Driven Design) + CQRS (command query responsability segregation), centrada en la parte de escritura. 1. Teoría --------- [](#1-teoría) A continuación, se explicarán los conceptos fundamentales de cómo diseñar una aplicación usando este framework, principios que son recomendables de seguir, aunque no obligatorios. ### 1.1 Arquitectura hexagonal [](#11-arquitectura-hexagonal) El diseño de la aplicación deberá seguir las recomendaciones de la arquitectura hexagonal mediante tres capas principales, aplicación, dominio e infraestructura. Y dos capas auxiliares, para utilidades y puntos de acceso. ``` ├─ Application ├─ Domain ├─ Infrastructure ├─ EntryPoint └─ Util ``` El diseño estará repartido en: - `Aplication` contendrá los comandos, handlers, cuyo objetivo es convertir peticiones externas, en peticiones a tu capa de dominio. - `Domain` contendrá la lógica de negocio repartida en modelos y servicios de dominio. - `Infrastructure` contendrá la implementación en tecnologías o servicios externos concretos de las dependencias de tu capa de dominio, como por ejemplo, los repositorios (para mongo, mysql, postgresql, etc). - `Util` contendrá utilidades genéricas propensas a ser usadas en cualquier capa. - `EntryPoint` estarán todos los puntos de acceso a los servicios de tu aplicación, como pueden ser comandos de consola, y controladores para peticiones vía API HTTP, etc. Y las normas son: - `Entrypoint` gestiona el problema de la inyección de dependencias con recursos como los contenedores de dependencias, el cual se encargará de inyectar las instancias de infrastructura a servicios de dominio; y éstos, a los de aplicación. - `EntryPoint` sólo puede usar clases de la capa de aplicación. - `Aplication` sólo puede usar clases de la capa de dominio. - `Domain` es totalmente independiente, y no conoce a nada que esté fuera (excepto utilidades). Las herramientas que se proporcionan en este mini framework, ayudan en algunos de estos puntos. ### 1.2 Event Sourcing [](#12-event-sourcing) La capa de dominio se compone de modelos (o entidades) mutables y ricos, con servicios e interfaces de repositorio que los persisten vía peticiones CRUD a una tabla concreta de dicho modelo. Event sourcing va mas allá, y consiste en persistir en una única tabla todos los eventos que ocurran en tu dominio de negocio. Los modelos se montarán ejecutando secuencialmente dichos eventos. Este modelo, se le suele conocer como agregado raíz, y puede estar compuesto por otros pequeños modelos, conocidos como agregados, que no puede ser gestionados de forma independiente fuera de este agregado raíz. Todas las operaciones realizadas sobre el modelo generarán un evento. La idea es invertir este proceso, y que sea el evento mismo, el que ejecute la operación sobre un modelo. ### 1.3 Asincronidad: Escritura VS Lectura [](#13-asincronidad-escritura-vs-lectura) Los eventos persistidos no son una forma eficiente de realizar operaciones de lectura sobre los datos de tu negocio, así que esta arquitectura prácticamente obliga a realizar CQRS desde el principio. Se recomienda tener el sistema de escritura totalmente independiente del sistema de lectura; y la comunicación entre estos dos sistemas, basada totalmente en una cola de mensajería consumida de forma asíncrona. En resumen, el sistema de escritura carga sus modelos leyendo eventos persistidos, y sus operaciones persiste y lanza nuevos eventos a un sistema de mensajería (rabbitMQ por ejemplo). Asíncronamente, los jobs (cron o worker) del sistema de lectura consumirá esos eventos con la intención de generar y persistir sus propios modelos de lectura, también conocidos como proyecciones. Estas proyecciones suelen ser persistidas en bases de datos orientadas a búsquedas complejas, como mongo, o elastic search. Desde que se lanza el evento, hasta que una proyección se lo aplica, va a pasar un margen de tiempo, donde el sistema de lectura tenga los datos desincronizados. A este problema se le conoce como consistencia eventual, y uno de las muchas tareas del programador es reducir este margen al mínimo, y gestionar conscientemente esta inevitable casuística cuando diseñe soluciones. También puede ser interesante que el sistema de escritura tenga sus propios consumidores de la cola de eventos, para desacoplar tareas y generar comandos que se ejecutarán igualmente de forma asíncrona. Todo es cuestión de cómo diseñes tu aplicación. Esta librería no trae utilidades significativas orientadas al sistema de lectura. 2. Comenzando ------------- [](#2-comenzando) Este es un pequeño tutorial para conocer poco a poco las partes que componen esta librería. \---POR HACER--- ### Health Score 27 — LowBetter than 49% of packages Maintenance20 Infrequent updates — may be unmaintained Popularity10 Limited adoption so far Community11 Small or concentrated contributor base Maturity58 Maturing project, gaining track record Bus Factor1 Top contributor holds 100% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Unknown Total 1 Last Release 1622d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/10d2cca40791a0a8dfdda64fe44f6421e73e0c907878032f4a40a3dbda827b85?d=identicon)[forkrefactor](/maintainers/forkrefactor) --- Top Contributors [![colybri](https://avatars.githubusercontent.com/u/17201057?v=4)](https://github.com/colybri "colybri (1 commits)") ### Code Quality TestsPHPUnit ### Embed Badge ![Health badge](/badges/forkrefactor-ddd/health.svg) ``` [![Health](https://phpackages.com/badges/forkrefactor-ddd/health.svg)](https://phpackages.com/packages/forkrefactor-ddd) ``` ### Alternatives [laravel/framework The Laravel Framework. 34.6k509.9M17.0k](/packages/laravel-framework)[laravel/horizon Dashboard and code-driven configuration for Laravel queues. 4.2k84.2M225](/packages/laravel-horizon)[stancl/tenancy Automatic multi-tenancy for your Laravel application. 4.3k6.6M40](/packages/stancl-tenancy)[shopware/platform The Shopware e-commerce core 3.3k1.5M3](/packages/shopware-platform)[magento/community-edition Magento 2 (Open Source) 12.1k52.1k10](/packages/magento-community-edition)[laravel/vapor-cli The Laravel Vapor CLI 31310.7M8](/packages/laravel-vapor-cli) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)