Welcome to crossword Discussions!

[dykyi-roman]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[dykyi-roman]

test

[bravik]

In terms of DDD how did Request objects and Twig extension end up in Application layer?
Requests are clearly a Presenation (or UI in your classification) layer. Symfony/HttpFoundation/RequestStack which you are using inside the Request objects is a clear indicator, that you have a dependency on presentation staff inside Application layer. Twig - is also about rendering/presentation.

In you deptrac you're not tracking vendor dependencies. Application and Domain layers should almost zero vendor dependencies. Only basic staff like webmozart/assert or uuid.

[bravik]

Actually what's the profit of using empty Request objects t all? it seems like just an useless extra layer of abstraction.
I see that there are some request which have assert validation. But I dont see any error handling logic or just don't have patience to dig and find it. Seems like you just make webmozart assertions which throw InvalidArgumentException. And in some places your custom assertions throw just RuntimeException.

Both of them will result in HTTP 500 for user. Which is unacceptable for validating user request. Request validation exceptions must provide HTTP 400 error at least, and clear per request attribute errors list (errors for all fields at once) at most. Which you can't implement using plain webmozart assertions. These assertions should be used mostly internally in domain layer. Requests should be validated on Presentation layer with something like symfony/validator.

[bravik]

Oh man... In fact you have infrastructure dependencies all around your domain and application... This is not DDD, as you are violating dependencies direction principle!

Symfony Messenger in domain? this is absolutely from infrastructure.

What you do with messenger should be done via some abstract EventDispatcherInterface defined in Application layer.
On Infrastructure layer you should have a MessengerEventDispatcher which should convert Domain event into Messager message.

To register message/event handlers you must not rely on Symony/messengers MessageHandlerInterface magic staff, but register your events in app's config by some domain EventHandlerInterface and messenger's service tag.

use XXX\Core\Common\Application\EventDispatcherInterface;
use Symfony\Component\Messenger\MessageBusInterface;

/**
 * Symfony Messenger adapter for Core event dispatcher
 */
class MessengerEventDispatcher implements EventDispatcherInterface
{
    private MessageBusInterface $bus;

    public function __construct(MessageBusInterface $bus)
    {
        $this->bus = $bus;
    }

    public function dispatch(object $event): void
    {
        $this->bus->dispatch($event);
    }
}

<?php

declare(strict_types=1);

namespace XXX\Core\Common\Application\Events;

/**
 * All core event handlers should implement this interface.
 * It can be used for handlers auto-configuration
 */
interface EventHandlerInterface
{
}

    # Register core event handlers
    _instanceof:
        XXX\Core\Common\Application\Events\EventHandlerInterface:
            tags: [messenger.message_handler]

[bravik]

While arguable, I personally came to understanding that:

• Domain layer basically describe the language.

• Domain layer should contain only Entities, Value Objects, Exceptions and Events raised in Entities (if there are any).

• Simple domain logic which is in scope of single entity and doesn't require any services goes to entities in Domain layer.

• Ports are not a part of Domain layer.

• Application layer contains UseCases, Ports (interfaces), Events and Handlers

• UseCases contain more complex domain logic which has several Domain Entities in scope.. UseCases use abstract Ports to abstract fron infrastructure layers.

• Repositories are same as Ports and belong to Application layer

• No vendor dependencies, except basic staff like webmozart asserts should be present in neither Domain nor Application layers.