Simple event sourcing – users, authentication, authorization (part 6)

Previously we spend some time preparing the code to support multiple kinds of events and data, rather than just supporting blog posts. In this part we’ll add user accounts, together with the required authentication and authorization code. We’ll again use event sourcing and the memory image to keep track of all users and currently active sessions. But the biggest changes to the application are related to security, and authorization in particular. It turns out event sourcing allows for an additional layer of authorization which allows us to whitelist any change a particular user is allowed to make.
Continue reading Simple event sourcing – users, authentication, authorization (part 6)

Simple event sourcing – refactoring and transactions (part 5)

In the previous part we added blog post comment functionality. In this part we’ll do some refactoring and change the memory image implementation to automatically retry domain logic on optimistic locking conflicts, giving us a simplified form of transactions. We’ll also change the event store to support multiple types of event streams in a single event store.

Continue reading Simple event sourcing – refactoring and transactions (part 5)

Simple event sourcing – consistency (part 2)

In the first part of this series we developed a simple blogging application that uses event sourcing to keep track of all changes made by the users. However, we did not yet write these events to durable storage. This means all data is lost when the application is restarted, which is clearly not acceptable. Saving and restoring events will be the responsibility of the event store, which we’ll start implementing in this part. But before we get to actually writing events to disk, we must first tackle the problem of maintaining data consistency when using event sourcing.

Continue reading Simple event sourcing – consistency (part 2)

Architect in Scrum

Last friday I gave a Masterclass called ‘Lean Agile Architecting’┬áto architects. Very interesting masterclass and a couple of things struck me. The issue for architects in an Agile environment is their position and responsibility.

The thing with the change from waterfall to agile is that architects feel their role is being undercut, the team just goes fast and are only paying attention to the Product Owner. The standard answer they seem to get is: ‘then join the team’, but they feel reluctant to do so, and most of the times they can not fully commit (full time). So they pass, and they feel miserable about it, since now this Agile project is going to make mistakes, and can not learn from past experiences and their expertise.

The answer lies in the closer observation of the definition of Agile and Architecture.
Continue reading Architect in Scrum