Domain Driven Design with Web API extensions part 10: the MongoDb context

Introduction

In the previous post we installed MongoDb locally. We also started the MongoDb server and connected to it with a client. We then inserted a test console application into our DDD skeleton project, imported the MongoDb .NET driver and connected to the MongoDb server using the driver.

In this post we’ll continue to explore the MongoDb context and some practical limitations compared to the automated tools available in EntityFramework. We’ll also add a new C# console library to the DDD skeleton project. The new library will eventually contain the MongoDb equivalent classes of what we have in the WebSuiteDemo.Loadtesting.Repository.EF layer.

Read more of this post

Advertisements

Domain Driven Design with Web API extensions part 9: setting up MongoDb

Introduction

In the previous post we set out the main topic of this new extension to the DDD model project. We said that we would add another repository mechanism, namely MongoDb. We went through the basic idea and some terminology behind MongoDb, e.g. what a document, a collection or an object ID means.

In this post we’ll set up MongoDb locally and try to connect to it from .NET using the MongoDb .NET driver.

Read more of this post

Domain Driven Design with Web API extensions part 8: domain repository with MongoDb

Introduction

Some months ago we went through an updated series on Domain Driven Design starting with this post. We built a functioning skeleton project with EntityFramework as the backing store, a Web API layer as the top consumer, a loosely coupled service layer and a central domain layer with some logic.

In this extension series we’ll investigate how to implement the domain repository in a data store that’s markedly different from SQL Server. In particular we’ll take a look at the NoSql document-based MongoDb.

Read more of this post

Domain Driven Design with Web API extensions part 7: domain events with RabbitMq completed

Introduction

In the previous post we set up the local RabbitMq environment. We also created a simple console application that built the message queue where the DDD demo project and the simulated financial application will communicate. We also prepared the way for the completion of the messaging process by creating an app setting reader and adding the RabbitMq related settings to web config.

In this post we’ll complete the demo by sending a message to the queue and reading it from the dummy financial console application.

Read more of this post

Domain Driven Design with Web API extensions part 6: domain events with RabbitMq

Introduction

In the previous post we looked at some basic theory behind messaging between independent applications. We discussed a couple of options to solve the problem. In this post we’ll start building our messaging environment using RabbitMq.

Read more of this post

Domain Driven Design with Web API extensions part 4: domain events in code

Introduction

In the previous post we looked at some theory behind domain events. We said that domain events were events that happen within a domain and that other components of the system may be interested in. The domain becomes the publisher – or producer – and the listeners will be the subscribers, or consumers of the domain messages.

We established that we’d solve the communication of consumers and subscribers through a mediator which stands in between. Publishers and subscribers will stay decoupled that way.

In this post we’ll implement the theory in C# code.

Read more of this post

Domain Driven Design with Web API extensions part 3: starting with domain events

Introduction

In the previous post we looked at how to apply the decorator pattern for our emailing scenario in the domain driven design demo project. We saw how the pattern helped us augment the functionality of the original TimetableService in an object oriented fashion. We also managed to wire up the decorator in StructureMap.

In this post we’ll solve the same problem in a different way. Well, at least we’ll start looking at another solution. Also, we’ll start discussing another concept from DDD: domain events. This part of the topic will be divided into two posts: the current post lays the theoretical foundations for the concepts and the next post will show the code.

Read more of this post

ultimatemindsettoday

A great WordPress.com site

Elliot Balynn's Blog

A directory of wonderful thoughts

Robin Sedlaczek's Blog

Developer on Microsoft Technologies

Softwarearchitektur in der Praxis

Wissenswertes zu Webentwicklung, Domain-Driven Design und Microservices

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT BEST PRACTICES WITH MICROSOFT STACK & ANGULAR

Cyber Matters

Bite-size insight on Cyber Security for the not too technical.

Guru N Guns's

OneSolution To dOTnET.

Johnny Zraiby

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

%d bloggers like this: