Skip to content
Yves Reynhout edited this page Jan 25, 2014 · 10 revisions

Introduction

Before you start using this library I'd like you to read some assumptions I'm making about you.

Value proposition

AggregateSource revolves around 3 main areas:

  • its core,
  • testing,
  • and integration with event storage mechanisms.

At its core AggregateSource offers a set of interfaces to build your domain model code with. Unlike state based models, backed by an Object/Relational mapper, it forces you to deal with initialization, transitions and change tracking explicitly. Fortunately, the learning curve is pretty cheap and blends well with behavior rich models. It's important to realize that AggregateSource will not make you a better modeler. Rather, it will enable you to build models, in code, using aggregates and eventsourcing. Learn more here ...

As you and your team explore the domain together with domain experts, you slowly come to grips with the problems to tackle. During those conversations a lot of sample scenarios will tend to emerge. AggregateSource.Testing helps you turn those scenarios into test specifications targeting one or more specific aggregates. To accomplish this, it uses a GivenWhenThen-like syntax specifically targetted at testing aggregates using events. It's NOT trying to be a general purpose BDD framework. Learn more here ...

Using both AggregateSource and AggregateSource.Testing you should be able to build up your entire model in code, driving all of the behavior with test specifications. Great! Except ... you need some form of persistence. This is where AggregateSource.EventStore and AggregateSource.NEventStore come in, both thin abstractions on top of and integrations with EventStore and NEventStore respectively.

Clone this wiki locally