{% extends 'web/layout.html.twig' %}

{% block page_title %}Blog - Qué diferencias existen entre el Domain Driven Design y otras metodologías de desarrollo{% endblock %}
{% block page_description %}Las diferencias principales entre Domain-Driven Design (DDD) y otras metodologías de desarrollo radican en su enfoque, objetivos y la manera en que abordan la complejidad del software{% endblock %}
{% block page_keywords %}Blog, Domain Driven Design{% endblock %}

{% block main %}
    <div class="container">
        <section id="title" class="mb-5">
            <h1>Blog - Qué diferencias existen entre el Domain Driven Design y otras metodologías de desarrollo</h1>
            <p class="lead">Las diferencias principales entre Domain Driven Design (DDD) y otras metodologías de desarrollo radican en su enfoque, objetivos y la manera en que abordan la complejidad del software</p>
        </section>
        <section id="diferences">
            <h2>Comparación entre DDD y otras metodologías</h2>
            <table class="table">
                <thead>
                    <tr>
                        <th>Aspecto</th>
                        <th>Domain-Driven Design (DDD)</th>
                        <th>Otras metodologías (ej. Waterfall, Clean Architecture, Agile, TDD, FDD)</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td>Enfoque principal</td>
                        <td>Centrado en el dominio del negocio y su modelado profundo.</td>
                        <td>Pueden centrarse en procesos, fases, pruebas, funcionalidades o arquitectura técnica.</td>
                    </tr>
                    <tr>
                        <td>Colaboración</td>
                        <td>Fomenta la colaboración constante entre desarrolladores y expertos del dominio.</td>
                        <td>La colaboración puede ser menos intensa o solo en ciertas fases (ej. toma de requisitos inicial).</td>
                    </tr>
                    <tr>
                        <td>Lenguaje común</td>
                        <td>Usa un lenguaje ubicuo: un vocabulario compartido entre todos los participantes.</td>
                        <td>No siempre enfatizan la creación de un lenguaje común o reflejado en el código.</td>
                    </tr>
                    <tr>
                        <td>Gestión de la complejidad</td>
                        <td>Divide el sistema en Contextos Delimitados y modelos ricos para manejar la complejidad.</td>
                        <td>Pueden gestionar la complejidad a través de fases, capas o módulos, pero no necesariamente alineados al dominio.</td>
                    </tr>
                    <tr>
                        <td>Adaptabilidad al cambio</td>
                        <td>Alta: el modelo evoluciona junto con el negocio, facilitando la adaptación a cambios.</td>
                        <td>Enfoques tradicionales (como Waterfall) son menos flexibles; otros como Agile buscan adaptabilidad, pero no necesariamente desde el modelado del dominio.</td>
                    </tr>
                    <tr>
                        <td>Patrones y técnicas</td>
                        <td>Incluye patrones tácticos y estratégicos específicos para el modelado del dominio.</td>
                        <td>Otros métodos pueden centrarse en patrones de arquitectura, pruebas o gestión de proyectos.</td>
                    </tr>
                    <tr>
                        <td>Objetivo final</td>
                        <td>Que el software refleje fielmente la lógica y procesos del negocio.</td>
                        <td>Puede priorizar la entrega continua, la cobertura de pruebas, la modularidad técnica, etc.</td>
                    </tr>
                </tbody>
            </table>
            <h2>
                Ejemplos de diferencias específicas
            </h2>
            <ul>
                <li><strong>Waterfall:</strong> Se basa en fases secuenciales y una toma de requisitos inicial, lo que puede generar productos poco alineados con el negocio si los requisitos cambian.</li>
                <li><strong>Agile:</strong> Busca adaptabilidad y entrega continua, pero no prescribe cómo modelar el dominio; DDD puede complementar Agile aportando profundidad en el modelado del negocio.</li>
                <li><strong>Clean Architecture:</strong> Se enfoca en la separación de capas y la independencia de la infraestructura, pero no obliga a modelar el dominio ni a usar lenguaje ubicuo o contextos delimitados.</li>
                <li><strong>TDD/BDD/FDD:</strong> Son metodologías orientadas a pruebas, comportamiento o funcionalidades, sin centrarse necesariamente en el modelado profundo del dominio.</li>
            </ul>
        </section>
        <section id="conclusion">
            <h2>Conclusión</h2>
            DDD se diferencia por su énfasis en el entendimiento profundo del dominio, la colaboración continua con expertos del negocio y el uso de patrones y técnicas que aseguran que el software refleje fielmente la realidad del negocio. Otras metodologías pueden ser complementarias, pero no abordan la complejidad del dominio con la misma profundidad ni promueven el mismo nivel de alineación entre tecnología y negocio.
        </section>

    </div>
{% endblock %}