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

Advertisement

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

Domain Driven Design with Web API revisited Part 4: the ubiquitous language and our refined problem domain

August 17, 2015 Leave a comment

Introduction

In the previous post we went through a couple of important terms in DDD and also started coding the foundations of the web suite demo app. In particular we discussed the meaning of bounded contexts and the shared kernel. Each domain object will be defined within a specific context, e.g. the load testing context and the web monitoring context as mentioned previously. There may be some sections where the contexts overlap. These sections are contained within the shared kernel that each bounded context can refer to. Finally we started building our code and introduced abstractions for the entities, value objects and aggregate roots.

In this post we’ll first introduce the concept of ubiquitous language and then sort out the key terms that describe our problem domain.

Read more of this post

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

Domain Driven Design with Web API revisited Part 3: shared kernel, bounded context and some initial code

August 13, 2015 2 Comments

Introduction

In the previous post we discussed 3 fundamental concepts in DDD: entities, value objects and aggregates with aggregate roots. We said that an entity is an object whose identity is defined by its ID key for the purpose of tracking its state through time. Its properties can change but its ID – whether a simple integer or a composite – should never be modified after the object has been created. Value objects on the other hand are defined by their properties and are immutable. We can say that a value object is also a type of entity but its ID is a composite of all its constituent properties. As the IDs are immutable per se, value objects are consequently also immutable. Finally, aggregates are groups of objects that are treated as a unit for purposes of data persistence. The “boss” of the group is the aggregate root and it’s through the aggregate root that other aggregates communicate with other aggregates.

In this post we’ll look at a concept called the shared kernel and how the above mentioned concepts can be represented in code.

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

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

%d bloggers like this: