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 , ,

Domain Driven Design with Web API revisited Part 12: testing the load testing database context

September 14, 2015 Leave a comment

Introduction

In the previous post we created our data store using EF code-first techniques. We also tested our overall database context by running a number of test queries to view and insert a couple of database objects.

We’re done with the data store but we’re not done with our load test context yet. Recall that the load test bounded context has its own well defined database context which is somewhat reduced compared to the full context. We need to test how it works.

Read more of this post

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

Domain Driven Design with Web API revisited Part 11: database creation and initial tests

September 10, 2015 2 Comments

Introduction

In the previous post we created the load test specific database context in a new repository layer. We also implemented the abstract timetable repository interface.

In this post we’ll create the database and fill it up with some initial values. The purpose of this post and the next is to see how our domain layer is reflected in the data store and to discover potential shortcomings and errors. I want to avoid the situation where we come to the final post where we test the web service layer and nothing works as it should. The tester application will be a simple C# console application.

Read more of this post

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

Domain Driven Design with Web API revisited Part 10: the load test database context

September 7, 2015 Leave a comment

Introduction

In the previous post we started building our EntityFramework repository layer. In particular we worked on the overall WebSuite database context which is meant to be an overall DB context object for all bounded contexts in the WebSuite application. It can be beneficial for each bounded context to have its own matching DB context so that it can concentrate on its DB-related tasks without interfering with other bounded contexts.

In this post we’ll build the load test DB context. This is also where we’ll implement the abstract repository interface we added earlier to the Domain layer.

Read more of this post

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

Domain Driven Design with Web API revisited Part 9: the overall database context

September 3, 2015 2 Comments

Introduction

In the previous post we looked at the repository pattern and abstract repositories in general. We discussed the role of repositories and saw how they can be useful in hiding the implementation details of the concrete data store solution. Repositories are great at limiting direct access to the data store from other layers of the application. They force external callers to go through the domain and its logic when performing data access related operations.

In this post we’ll start implementing the repository for our aggregate root, i.e. the Timetable object. There’s a lot of ground to cover so the topic will span two posts. We won’t create the database yet. That is the subject of another post that follows upon completing the concrete repository layer. The following several posts will be quite technical in nature as opposed to what we’ve seen so far.

Read more of this post

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

Domain Driven Design with Web API revisited Part 8: the abstract repository

August 31, 2015 1 Comment

Introduction

In the previous post we finished working on our domain layer. We have built the aggregate root of our load test aggregate, i.e. the Timetable object. It is meant to act as an umbrella for Loadtest-related operations. We can also consider it as a domain service. External callers that wish to interact with load tests must do so through the Timetable object.

However, that is not the entire story as far as data storage is concerned. In this post we’ll start discussing repositories.

Read more of this post

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

Domain Driven Design with Web API revisited Part 7: the aggregate root in our domain model

August 27, 2015 Leave a comment

Introduction

In the previous post we discussed the concept of associations and standalone classes. We saw why it was important to keep the coupling between domain objects at a minimum. We also built the central object in our load test domain, Loadtest.cs.

In this post we’ll take a step upwards and discuss the root of the load test aggregate.

Read more of this post

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

← Older posts

Newer 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

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