search

thenativeweb / node-cqrs-domain

Node-cqrs-domain is a node.js module based on nodeEventStore that. It can be very useful as domain component if you work with (d)ddd, cqrs, eventdenormalizer, host, etc.
http://cqrs.js.org/pages/domain.html
MIT License
269 stars 57 forks source link

Aggregate schema validation #109

Closed alemhnan closed 6 years ago

alemhnan commented 6 years ago

Hello,

this is not an actual issue but a proposal/idea/nice to have. The title is already explicit, what I would like to have is the possibility to declare a schema for the aggregate in the same way that is done for commands/events. The reasoning is that sometimes different commands on the same aggregate are modifying the data structure and it's not really evident until you break things.

Would it make sense? Would be feasible to do with the current setup? I'm willing to take a shot at this and open a PR, if that makes sense of course.

adrai commented 6 years ago

This was in discussion some years ago... If I remember correctly the main reason to not do this, was because it already is. Your commands are validated and the events are created explictly in the domain by code. So finally the aggregate is valid too. And because the aggregate state is only in memory you can change it on your needs, by changing the way you apply the events and your business rules. By this I mean, because you need to test all your business domain behaviour anyway, it's not important how stuff is temporarely saved on your aggregate. The important stuff is your business rules/behaviour. A validation of your aggregate state would only distract from owning and really knowing your domain. Perhaps I described this in a too phylosophical way...

alemhnan commented 6 years ago

Nono, it's not too philosophical and makes a lot of sense.

In my case, we are building the project from scratch and we are to the point of which we do know the domain quite well. At one point though, this knowledge should be transferred to other team members and there will be the case I will not be on this project anymore (I'm a contractor). That means that it will be a nice to have to have explicitly declared the aggregate data structure as it becomes easier to share that bit of knowledge.

Now that I am writing I think that more than the validation itself I like to have the aggregate schema as an explicit first class artifact. Makes easier to reason about it, you can develop tools against it (e.g. for commands we have an automatic swagger rest API built based on the schemas).

I agree though that it's not strictly necessary but only a nice to have.

In case we will decide to do internally, how you would suggest to do it? Is it possible to add that as an extension directly from this package?

adrai commented 6 years ago

You can start to fork this repo and create a PR... and after this we can decide to include it or encapsulate to an other module, ok?

alemhnan commented 6 years ago

Sounds good yep. I'll talk with my colleagues and see where this will go.