Domain Driven Design with Web API extensions part 5: domain events between independent systems

November 5, 2015 1 Comment

Introduction

In the previous post we looked at a solution on how elements of a .NET solution can communicate with each other using a mediator. The mediator keeps the publisher decoupled from the subscribers. Also, the mediator won’t have any knowledge of the event handlers, their exact types and what and how they will handle the messages from the domain objects.

The solution helps the email sending event handler read the domain event in case a user added a new or updated an existing load test. In this post we’ll direct our attention to messaging between independent applications. We’ll ultimately simulate that a financial application also wants to be notified of the load test domain events in order to calculate the monthly profits.

Read more of this post

Advertisement

Filed under .NET, Design patterns, Messaging Tagged with , , , , ,

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

November 2, 2015 1 Comment

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

Filed under .NET, Design patterns, Design principles, web api 2 Tagged with , , , ,

Domain Driven Design with Web API extensions part 2: notifications with the decorator pattern

October 26, 2015 Leave a comment

Introduction

In the previous post we started building an extension to our DDD skeleton project. We saw a simple way of adding a component to the TimetableService so that we could send an email upon inserting or updating a load test. We also discussed the pros and cons of the current implementation.

In this post we’ll see an alternative solution using the Decorator design pattern.

Read more of this post

Filed under .NET, Design principles Tagged with , , , ,

Domain Driven Design with Web API extensions part 1: notifications

October 22, 2015 3 Comments

Introduction

A couple of weeks 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 a couple of ways to add various dependencies to the project. In particular we’ll look into how to send email notifications in case a new load test has been booked.

Read more of this post

Filed under .NET, Design principles, Web API Tagged with , , , ,

Domain Driven Design with Web API revisited Part 18: tests and conclusions

October 5, 2015 2 Comments

Introduction

In the previous post we continued working on our Web API 2 layer and added two new controller actions: POST which handles both updates and insertions and DELETE which is responsible for deleting load tests. Our first draft of the DDD load testing demo is actually finished at this point. All that’s left is testing the POST and DELETE functions of the Web API.

We’ll do that in this post. We’ll also write some conclusions.

Read more of this post

Filed under .NET, Design principles Tagged with , , ,

Domain Driven Design with Web API revisited Part 17: the POST and DELETE controller actions

October 1, 2015 Leave a comment

Introduction

In the previous post we started building the top layer of our load testing DDD demo solution. We added an empty Web API 2 project and also created a GET controller action to retrieve the open load tests 2 weeks ahead. We also managed to add an IoC controller called StructureMap which injects the required concrete dependencies into the controllers and service methods.

In this post we’ll continue building on our demo project and add the POST and DELETE controller actions as well. We’ll also see another application of the view-model concept we saw earlier.

Read more of this post

Filed under .NET, Design principles Tagged with , , ,

Domain Driven Design with Web API revisited Part 16: the Web API consumer layer and the GET controller action

September 28, 2015 1 Comment

Introduction

In the previous post we built the concrete application service layer for our demo project. We saw that it was quite straightforward to implement the abstract service we inserted in the post before that.

It is time to build the top layer of the solution which will communicate with the application service. This post will be quite technical as we need to add an IoC container to the Web API project.

Read more of this post

Filed under .NET, Design principles Tagged with , , ,

Domain Driven Design with Web API revisited Part 15: the concrete application service

September 24, 2015 1 Comment

Introduction

In the previous post we looked at application services in general. We saw that they connect the ultimate consumer layer, such as MVC with the domain layer. They have no or very little logic. Instead, they act as coordinators. They accept requests from the consumer layer and make sure that the consumer layer gets back a valid response. The consumer won’t care how the application service carries out its job and what concrete dependencies it may have.

In this post we’ll build upon the abstract timetable service and basic messaging classes. The goal is to build a functioning service layer.

Read more of this post

Filed under .NET, Design principles Tagged with , , ,

Domain Driven Design with Web API revisited Part 14: the abstract application service

September 21, 2015 Leave a comment

Introduction

In the previous post we discussed the role of view models. We saw that they are simple classes with a collection of properties and usually no logic. They can be used to format the domain object in a special way that fits a specific purpose without having to change the domain object itself. E.g. the UI of the application can show the domain in a specialised way, like we hinted at in the previous post: customer name instead of customer ID, agent country and city instead of agent ID etc.

In this post we’ll start discussing the application service layer. In particular we’ll build the abstract service and the messaging objects. We’ll build the concrete application service in the next post.

Read more of this post

Filed under .NET, Design principles Tagged with , , ,

Domain Driven Design with Web API revisited Part 13: view models

September 17, 2015 1 Comment

Introduction

In the previous post we tested the load testing database context. We saw how EF could transform the database objects into domain ones through reflection. However, we had to add some changes to the domain code in order to support this feature. The domain objects lost their persistence ignorance feature to some extent but I think we were able to minimise the “damage”. One such change was the addition of a private parameterless constructor which really has no role for the domain but helps us implement EntityFramework as the backing store mechanism.

In this post we’ll look at view models.

Read more of this post

Filed under .NET, Design principles Tagged with , ,

← Older posts

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Once Upon a Camayoc

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

%d bloggers like this: