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

Domain Driven Design with Web API revisited Part 6: associations and standalone classes

August 24, 2015 2 Comments

Introduction

In the previous post we built up the objects that will surround the central domain object, i.e. Loadtest. We saw examples of entities and value objects. We are deliberately keeping the objects simple so as to keep the size of the demo manageable for a blog like this. Always keep in mind that real-life domain objects will be more complex than those but our main goal is to concentrate on a small section.

In this post we’ll connect the dependent objects with Loadtest. We’ll also look at two new concepts from DDD: associations and standalone classes.

Read more of this post

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

Domain Driven Design with Web API revisited Part 5: starting with the domain in code

August 20, 2015 2 Comments

Introduction

In the previous post we discussed the concept of ubiquitous language in DDD. It describes the problem domain in clear terms that are well-known for each stakeholder in the project. Each bounded context has its own well defined ubiquitous language that all parties stick to in every form of communication. We also defined the most important terms and rules for load testing bounded context of our demo application.

In this post we’ll start coding the domain objects. My intention is to be as detailed as possible as the domain layer is the most important on in a DDD project. Therefore this section will span two blog posts.

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.