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

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

Advertisements

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

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

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

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

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

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

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

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

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

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

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

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

ultimatemindsettoday

A great WordPress.com site

Elliot Balynn's Blog

A directory of wonderful thoughts

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 TUTORIALS WITH OPEN-SOURCE PROJECTS

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: