search

meteor-space / event-sourcing

CQRS and Event Sourcing Infrastructure for Meteor.
MIT License
63 stars 9 forks source link

Feature/aggregate di #52

Closed qejk closed 8 years ago

rhyslbw commented 8 years ago

I need to prioritise the next release's breaking changes and there's a bug we need to investigate too. This can go to a minor release 3.x.0 if needed, but having said that, are there any issues with this from your point of view, or do we just need code review?

qejk commented 8 years ago

Forgot there is better way to handle commands and events on existing aggregate - will tackle that today. Then tests, and were done here.

rhyslbw commented 8 years ago

Ok, then let's bring it into 3.0.0 as it's a nice feature worthy of the major release

rhyslbw commented 8 years ago

See: https://github.com/meteor-space/messaging/issues/28

I think this in combination with CommandBus/EventBus middleware will be the best approach for command validation and configuration-based business rules. Let's try to wrap the feature here so it's in the 3.0.0 release.

rhyslbw commented 8 years ago

@DominikGuzei I've just assigned this to you for review. Looks good to me

rhyslbw commented 8 years ago

Just punted this non-breaking feature to the next feature release as it's now the only blocker for 3.0.0

darko-mijic commented 8 years ago

We need changelog updated and version number before the release

DominikGuzei commented 8 years ago

Ah sorry for that, im deep in another project and problem solving :wink: should not merge in that case.

darko-mijic commented 8 years ago

It is fine. We will cover that in release branch.

rhyslbw commented 8 years ago

We need changelog updated and version number before the release

@meteor-space/core In future let's try to ensure any new features are added to the changelog under the heading "next". Version numbers should remain only a concern of the release, managed in a separate branch.

darko-mijic commented 8 years ago

@meteor-space/core In future let's try to ensure any new features are added to the changelog under the heading "next". Version numbers should remain only a concern of the release, managed in a separate branch.

Yes, this is a very good practice introduced by Rhys which makes releases easy. And author of the change probably is the best person to write what is changed rather then reviews. I would also suggest that we add snippets of examples how new features can be used. We can move that to proper documentation and link to it from the changelog eventually. Shall we restore this branch?

rhyslbw commented 8 years ago

No a merge is a merge, if anything a new chore branch

darko-mijic commented 8 years ago

OK, than we should delete this branch and create a new one.

darko-mijic commented 8 years ago

I would also suggest that we add snippets of examples how new features can be used.

This is one possible approach for creating the documentation (for new features that must touch on some existing features and therefore have even more value) while generating documentation from comments is not there.

darko-mijic commented 8 years ago

@meteor-space/core Shall we consider releasing this?

qejk commented 8 years ago

Imo we should have examples pointing out good and bad practices here - since someone can assume full freedom while using DI and its not the case here.

darko-mijic commented 8 years ago

I started using this today. I have real world examples. Maybe we should join or experiences @qejk and continue working on this. This is really good and worthy contribution to ES aggregates/processes. We should also address current implementation of aggregate states. And messaging middleware.