Various topics from software architecture part 5: aggregate roots

Introduction

In the previous post we looked at the second installment of the unit of work pattern. We designed a mock implementation of the unit of work and unit of work repository interfaces.

In this post we’ll look at a key concept from Domain Driven Design, the aggregate root. This topic was discussed in detail as part of the DDD series but it deserves a dedicated post.

Read more of this post

Advertisements

Various topics from software architecture part 4: the unit of work continued

Introduction

In the previous post we looked at the basic goals and the abstractions associated with the unit of work pattern. We came to the conclusion that it might not be necessary to introduce an abstraction for the unit of work to begin with as modern ORMs like EntityFramework already have a well-tested unit of work object inside. There may still be cases though where you can make use of the pattern and the associated unit of work repository.

In this post we’ll see some possible mock implementations of these abstractions and how they can be wired up in the repository layer.

Implementation stubs

We’ll briefly look at some implementation skeletons for the IUnitOfWork and IUnitOfWorkRepository interfaces and how they can be used in a concrete repository.

Read more of this post

Various topics from software architecture part 3: the unit of work

Introduction

In the previous post we looked at a basic implementation of the Repository pattern. We said that this pattern is often used in large layered projects where persistence ignorance of the domain layer is a requirement. It is also very useful in unit testing where you want to avoid calling a real data store and instead create mocks or stubs for the repository.

In this post we’ll look at another concept that comes up in conjunction with data access: the unit of work. We’ll also refer back to the previous post on the Repository pattern here and there as the Unit of Work pattern is often used in conjunction with repositories.

This post will be more concerned with abstractions. The next post will continue with some implementation stubs.

Some of the explanations are taken directly from the series on domain driven design so they might look familiar if you’ve seen that.

Read more of this post

Various topics from software architecture part 2: the Repository pattern

Introduction

In the previous post we looked at the RequestResponse messaging pattern. This pattern is often used in Service Oriented Architecture projects to simplify the communication between the service and its client.

In this post we’ll look at something very different. The Repository pattern is frequently employed in layered architectures where the domains in the Domain layer expose data access related operations through abstract interfaces. The actual repository layer, e.g. EntityFramework or MongoDb then implement those interfaces.

The primary goal of the Repository pattern is to decouple the domain objects from the physical repository layer. The domain objects and the domain layer are not supposed to know about the actual data access operations such as opening a database connection and querying a database. This is a common approach in Domain Driven Design (DDD).

We’ll go through the basic concepts of the pattern in this post. If you’d like to see a more complex design then you can go through the series on DDD. Also, there are multiple ways to implement the pattern but the main objective is to keep the technology-specific data access operations out of the domain layer.

A simple domain

Read more of this post

Various topics from software architecture part 1: the RequestResponse messaging pattern

Introduction

In this series we’ll look at a couple of topics from the world of software architecture. If you have read other architecture-related series on this blog then some of them will be familiar to you by now.

I’m planning to write an updated series dedicated to Domain Driven Design during/after the summer of 2015. I don’t want to rewrite everything that’s been said in the original series. Therefore I decided to factor some major chunks out into separate posts for easier reference. Most of them appear within the series but are “hidden”, meaning it’s difficult to just refer to them separately.

We’ll start by looking at a simple pattern used in messaging, called RequestResponse.

The RequestResponse

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: