Command validation about commanded HOT 8 CLOSED

My 2 cents:

Vex was my initial choice for my in-house CQRS implementation too. However, since a lot of commands in my system are tightly bound to a forms, where I have some possibly nested structures, I switched to JSON schema for the initial command format validation.

Basically I have single field in my command struct that is data. It gets first validated agains json schema, using https://github.com/jonasschmidt/ex_json_schema

This initial validation, I call it "command format validation" since it is not touching any business logic. It gets performed also before I pass the command for execution to aggregate, within the context of a cowboy/phoenix worker that handles commands itself.

When I pass the command to aggregate, it can also fail, because of some business rules. Say, balance not enough to make transfer. In such case I return errors, exactly the same way (from client's point of view) as I would during the initial command format validation.

from commanded.

@hubertlepicki Thanks for your input. Agreed that this should be limited to command format validation. The aggregate should handle business rule validation. It's a neat idea to use the same validation failure structure for both types of validation.

Rather than dictating an approach perhaps I should provide a command validation protocol that the consumer could implement. This would support different validation strategies for individual commands. I've used a protocol to allow extension of the JSON serializer in a similar way (ec796b1).

from commanded.

@hubertlepicki Do you have any plans to open source the CQRS library you're working on? Would be interesting to share ideas.

from commanded.

@slashdotdash at this stage I am missing the point. Your implementation is already more complete, and simply better for the most part. I am playing with your system now, I may be able to help with a few things but first need to get a better feeling of it. Tests are good, thanks for that, helps a lot <3

from commanded.

One more thought about commands validation. There's a temptation to overuse it, which I do not think should be encouraged.

For example, one could build a CQRS system where they simply send the commands and, they get validated on the server-side and return a map of field/error pairs, that then are used to display errors. Say {"email" => "already taken", "password" => "can't be blank"} etc..

I think this is short-sighted, as it generally puts loads of workload on the domain model/aggregates/"write" server etc, whatever you call it.

Instead we have a read model that should be queried by the client to figure out if the command will succeed, before issuing it.

What I am trying to say is that the tool we use influences our style of programming. If we provide full featured, user-friendly error messages people will be using them instead of querying domain model.

In my system I did exactly that, return really nice validation errors to the client when command fails, even run them through gettext so the clients can simply display it next to form fields. And I know I should be using read model instead, but I still don't - for the most part - because I am lazy!

So what I am trying to say is maybe you don't want to return nice validation errors to clients. Just return something that indicates that command schema is invalid, or a business logic error reason from the aggregate. What do you think about that?

from commanded.

I'm also thinking about declarative conversion of json/map payloads to command structs,
to eliminate needs of manual rewriting all fields from map to struct. Something which can looks like:

defmodule Payload do
  use MapToStructConverter

  convert %{"command" => "create_bank_account"}, to: CreateBankAccount
  convert %{"command" => "create_bank_account", "version" => "1"}, via: Versions, to: CreateBankAccount
  convert %{"command" => "create_bank_account", "version" => "2"}, to: CreateBankAccount
end

and put it on pipeline between web input and command router. In case when payload not match any command then should fail immedietly

in the simple use case conversions between versions of payload could be done on the fly by leaving fields of struct not filled/initialized.

from commanded.

This issue may be superseded by #12 Command handling pipeline. The pipeline feature would allow you to create your own validator and plug into all command dispatching. Without requiring a specific implementation being provided here.

from commanded.

Validation may now be implemented as command dispatch middleware following the changes included in #26.

An example validation middleware module is given below. This can be used to integrate with any third party validation library (e.g. Vex) or your own.

defmodule Validation do
  @behaviour Commanded.Middleware

  alias Commanded.Middleware.Pipeline
  import Pipeline

  def before_dispatch(%Pipeline{command: command} = pipeline) do
    case valid?(command) do
      true -> pipeline
      false ->
        pipeline
        |> respond({:error, :validation_failure, validation_errors(command)})
        |> halt
    end
  end

  def after_dispatch(pipeline), do: pipeline
  def after_failure(pipeline), do: pipeline

  defp valid?(command) do
    # your command validation logic (e.g. using Vex)
  end

  defp validation_errors(command) do
    # return validation failures
  end
end

Closing this issue.

from commanded.