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

Architecture

Avoiding the Repository Pattern with an ORM

For many years now I’ve advocated not using the repository pattern on top of an ORM such as Entity Framework. There are many reasons why that I’ll try and cover throughout this post based on ways that I’ve seen it implemented. Meaning, this post is talking about poorly implemented approaches or pitfalls that I’ve seen. To clarify, since this topic seems to really fire people up, I’m not saying that you shouldn’t use the repository pattern. I’m going to clarify why I don’t think under certain situations it’s very useful and other situations that I do find it useful. This… Read More »Avoiding the Repository Pattern with an ORM

4+1 Architectural View Model

It’s incredibly difficult to describe a complex system, regardless if you are developing a monolith or (micro) services. Use cases, code organization/navigation, interactions between services, and deployment/infrastructure are just some of the aspects that comprise the architecture of an entire system. Depending on your role as a stakeholder, your view of the system can be very different than another stakeholder. This blog post is in a series. To catch up check out these other posts: Context is King: Finding Service Boundaries Language Autonomous Services Focus on Service Capabilities, not Entities Context Matters There are many different stakeholders related to a… Read More »4+1 Architectural View Model

Focus on Service Capabilities, not Entities

One of the most common pitfalls I think I’ve fallen into is focusing too much on data entities rather than service capabilities. What tends to happen is building up a domain model of behaviors related to single entities. As I’ve mentioned in my post about using language to find service boundaries, you can have the same entity that lives in a different context, but that owns specific behaviors and data. This blog post is in a series. To catch up check out these other posts: Context is King: Finding Service Boundaries Language Autonomous Services 4+1 Architectural View Model Entities I’m… Read More »Focus on Service Capabilities, not Entities