I'm trying to get my head around the concept of event-sourcing based architecture. From my understanding, the projection is the representation of a state in a given point of time; in fact - it's an aggregation of events which led to that state. The projection is being stored in a data store for purpose of querying.Since both the aggregate and the projection are being rebuilt from stream of events, why shouldn't I merge them into single code piece?I'd end up with a class that would be responsible for:updating it's (internal) state based on applied eventscreating new events when asked to change its stateFor instance: the shop order. Assuming we have an infrastructure which stores the events, and dispatches them to the projections, then stores the projections class Order: Aggregate {    private Guid _id;    private OrderState _state;    private DateTime _dateCreated;    private List<Item> _items = new List<Item>();    public Order()    {        // used when loading from projection data store (de-serializing from JSON for example)    }    public Order(Guid id, IEnumerable<Item> items)    {         // used when handling CreateOrder command,        // uses Aggregate.PublishEvent which appends the event to the stream        // the event dispatcher causes the event to be Applied as well        this.PublishEvent(new OrderCreated(id, items));    }    public void Apply(OrderCreated ev)     {        // event applied by event dispatcher, when reconstructing from events        this._id = ev.Id;        this._state = OrderState.New;        this._items = new List<Item>(ev.Items);    }    public void Ship()    {        // used when handling ShipOrder command        // incorporates business logic        if (this._state != OrderState.Shipped)        {            this.PublishEvent(new OrderShipped(this._id));        }    }}
Event sourcing: merging aggregate root and projection?
c#;domain driven design;cqrs;event sourcing