Dennis Doomen 2
Dennis is an agile .NET architect with a broad interest in modern software development, Domain Driven Design, CQRS, Event Sourcing and everything agile. He specializes in designing enterprise solutions based on the .NET technologies as well as providing coaching on all aspects of designing, building and maintaining enterprise systems. He is the author of www.fluentassertions.com, an assertion framework for fluently asserting the outcome of unit tests and he has publishing coding guidelines for C# 3.0, C# 4.0 and C# 5.0 on www.csharpcodingguidelines.com since 2001. He also maintains a blog on his everlasting quest for better solutions at www.continuousimprover.com. You can reach him on twitter through @ddoomen.
Präsentationen bei der .Net User Group Bern
Using OWIN to decompose a monolith into microservices
Using the Open Web Interface for .NET to decompose a monolith into microservices. If I have to name a single hype in software architecture land then I would have to mention the micro-service architecture. Microservices are supposed to be small, have a very focused purpose, can be deployed independently, are completely self-supporting and loosely coupled. Ideally, microservices are technology agnostic, but hey, we're in the .NET space, aren't we? And they are not a goal, but a means to an end. In fact, a microservice architecture has many benefits and are a great strategy for decomposing a monolith. So how do you build a microservice? What technologies does the .NET realm offer for us? And what if you don't want to deploy them independently? In this talk, I'll show you some of the pros and cons of microservices and how you can leverage Event Sourcing, OWIN and .NET to move your monolith into a bright new future.
Building Occasionally connected applications with Event Sourcing
Building occasionally connected applications using Event Sourcing. I've recently got the opportunity to work on a large enterprise-class system that needs to be deployed on multiple occasionally connected oil platforms and boats. Already the system's architecture was based on the Command Query Separation principles; this gave us a completely new challenge. After several months of looking at alternatives, we decided to go the Event Sourcing direction. In this in-depth session, I'd like you to learn the many alternatives we observed, the pros and cons, and the technical details of our final solution in which we use EventStore 3.0 and elements of NCQRS and Lokad.CQRS to synchronize systems over unreliable connections in a very efficient way. And for those who are new to CQRS, don’t worry. I’ll will bring you up to speed on the different architecture styles.