Skip to content

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


Follow @CodeOpinion

Patterns

Eventual Consistency and Business Alignment

I recently discovered through eventual consistency that my bounded contexts were not properly aligned with the business.   I won’t lie, it took me quite a while to make this realization. This was most likely the case in many situations I’ve had in the past.  Because of this realization, I wanted to let out some of my thoughts about eventual consistency and business alignment. Dependent Bounded Context I’ve often encounter situations where a bounded context requires information that another bounded context is responsible for.  I’d like to use a simple example I’ve heard from Udi Dahan.  In the context of an Ecommerce site. A… Read More »Eventual Consistency and Business Alignment

Query Objects with a Mediator

In my previous blog Query Objects instead of Repositories, I demonstrated creating query objects and handlers to encapsulate and execute query logic instead of polluting a repository with both read and write methods.  Since we have moved away from repositories and are now using query objects, we will introduce the Mediator pattern. It will allows have a common interface that can be injected into our controller or various parts of our application. The mediator will delegate our query objects to the appropriate handler that will perform the query and return the results. First we will create an interface that will… Read More »Query Objects with a Mediator

Query Objects instead of Repositories

The repository pattern is often used to encapsulate simple and sometimes rather complex query logic.   However, it has also been morphed into handling persistence and is often used as another layer of abstraction from your data mapping layer.   This blog post show you how to slim down and simplify your repositories or possibly eliminate them all together by using query objects. A typical repository will look something like this: public interface IProductRepository { void Insert(Product product); void Delete(Product product); IEnumerable<Product> GetById(Guid id); IEnumerable<Product> GetAllActive(); IEnumerable<Product> FindByName(string name); IEnumerable<Product> FindBySku(string name); IEnumerable<Product> Find(string keyword, int limit, int page); IEnumerable<Product> GetRelated(Guid id); } Each… Read More »Query Objects instead of Repositories