Por lo general, desarrollamos negocios para proyectos web, la mayoría de los cuales se basan en la arquitectura MVC de tres niveles del modelo de anemia, que es un estilo de programación típico orientado a procesos. Por el contrario, el modelo de desarrollo DDD basado en el modelo de congestión es un estilo típico de programación orientada a objetos. Sin embargo, DDD no es una fórmula mágica. Para el desarrollo de sistemas con negocios sin complicaciones, el modelo de desarrollo tradicional basado en el modelo de anemia es simple y suficiente, mientras que el modelo de desarrollo DDD basado en el modelo de congestión es un poco excesivo y no puede funcionar. Por el contrario, para el desarrollo de sistemas complejos de negocios, el modelo de desarrollo DDD requiere más tiempo y energía en el diseño para mejorar la reutilización y mantenibilidad del código, por lo que es más que el modelo de desarrollo basado en el modelo de anemia. Hay ventajas.
En comparación con el modelo de desarrollo tradicional, la principal diferencia entre el modelo de desarrollo DDD basado en el modelo de congestión es la capa de servicio. En el modelo de desarrollo basado en el modelo de congestión, trasladamos parte de la lógica de negocio original en la clase Servicio a un modelo de dominio de dominio congestionado, de modo que la implementación de la clase Servicio depende de esta clase de dominio. En el modo de desarrollo DDD, la clase Service no se eliminará por completo, pero es responsable de algunas funciones que no son adecuadas para colocarse en la clase Domain. Por ejemplo, es responsable del trabajo no funcional, como tratar con la capa de repositorio, las funciones de agregación empresarial de los modelos de dominio cruzado y las transacciones idempotentes. En comparación con el modelo de desarrollo tradicional basado en el modelo de anemia, el modelo de desarrollo DDD basado en el modelo de congestión tiene básicamente el mismo código en la capa Controlador y en la capa Repositorio. Esto se debe a que el ciclo de vida de la entidad de la capa de repositorio es limitado y el VO de la capa de controlador es puramente un DTO. La lógica empresarial de las dos partes no es demasiado complicada. La lógica empresarial se concentra principalmente en la capa de Servicio. Por lo tanto, la capa de repositorio y la capa de controlador siguen utilizando la idea de diseño del modelo de anemia no es un problema.