2

Lets say i have distributed architecture (client-server). On client side there is ServerEntity class, on the client side its ClientEntity class. I want ClientEntity simply to request some data from ServerEntity. I started learning DDD approach recently and actually I like domain events so I went with it. Here is my simplifed expectation of the future implementation:

  1. ClientEntity creates command RequestDataCommand and publishes it (e.g. through MessageBus)
  2. Client's ApplicationLayer gets this command, wires up it and sends to server
  3. Server's ApplicationLayer receives command and pushes command to MessageBus
  4. ServerEntity receives command and publishes domain event with some data
  5. Server's ApplicationLayer gets this events, wires up it and sends to the client
  6. Client's ApplicationLayer receives event and pushes command to DomainEventManager
  7. ClientEntity is subscribed for the event and when recieves it changes some internal state.

The disadvantage of the approach above is that we will end up with dozens of command classes.

On the other hand there is another option: we create some domain service interface like IRequestDataService and make it as dependency for ClientEntity. Thus we will not need to create command class and pass it to message bus, we just call appropriate method from IRequestDataService. Responces from server are recieved as domain events like in previous example.

The disadvantage of the second approach is that we use service just to send commands, which is in my vision should execute only synchronous operations.

Which approach is better and do I think the right way about client-server communication?

eulerfx
  • 36,769
  • 7
  • 61
  • 83
garf
  • 53
  • 1
  • 5

1 Answers1

0

Your RequestDataCommand doesn't look like a command to me.

A command is an imperative directive using the UL, which changes the state of your system. Requesting data does not change state, so it shouldn't be a command.

Your second approach suffers from the similar problem. The call to IRequestDataService should not change the state on the server. No state change means no events should be fired, at least not in "normal" DDD.

My impression is that you are trying to use the infrastructure you have (Events, Message bus, ...) to do something you shouldn't.

In my opinion, for reading data a better option would be to bypass most of the domain logic and just read the data the most simple and straightforward way. Take a look at CQRS (http://martinfowler.com/bliki/CQRS.html is a good start)

Lev
  • 309
  • 1
  • 12