Value Objects in C#
In this article, we are going to dive into a very interesting concept in domain-driven design: value objects. We will take a look at many aspects of value objects, what makes them useful, and discuss situations where they may not be appropriate.
What's enough Complexity for a Domain Model?
Should you be applying domain-driven design? Do you need a domain model? You might want to if you have a lot of complexity within your domain. I often get asked, “what is a lot of complexity?”. I’m going to provide an example by uncovering more and more complexity within a domain. And give a few different insights that should help you make the decision.
SOLID? Nope, just Coupling and Cohesion
How do we avoid writing spaghetti code so our systems don’t turn into a hot mess? For me Coupling and Cohesion. Some people focus on things like SOLID principles and Clean Architecture. While I don’t necessarily have a problem with that if you’re pragmatic, I don’t ever really think about either of those explicitly.
Marten just got better for CQRS architectures
’m assuming some prior knowledge of Event Sourcing as an architectural pattern here. I highly recommend Oskar Dudycz’s Introduction to Event Sourcing training kit or this video from Derek Comartin. While both Event Sourcing and the closely associated CQRS architectural style are both useful without the other, I’m still assuming here that you’re interested in using Marten for event sourcing within a larger CQRS architecture.
Message Ordering in Pub/Sub or Queues
Do you need message ordering? Processing messages in order as they were sent/published to a queue or topic sounds simple but has some implications. What happens when processing a message fails? What happens to all subsequent messages? How is throughput handled when using the competing consumers’ pattern, which loses the guarantee processing in order. Lastly, is ordering even important?
Domain Modeling - Encapsulation
Domain Modeling - Encapsulation Date Published: 18 May 2022Domain models should encapsulate logic operations so that there is only one way to perform a given logical operation. That means avoiding exposing entity state and ensuring operations flow through specific methods. By funneling specific oper...
Commands & Events: What’s the difference?
One of the building blocks of messaging is, you guessed it, messages! But there are different kinds of messages: Commands and Events. So what’s the difference? Well, they have very distinct purposes, usage, naming, ownership, and more!
Commands, Events, Versions, and Owners
Commands and events are two common types of messages used in distributed application architectures, including microservice designs. When the definition of these messages needs to change, which application "owns" the message and is responsible for upgrading and versioning its schema?
Real-World Event Driven Architecture! 4 Practical Examples
Event Driven Architecture has many benefits. Loose and temporal coupling, scaling, resilience, and more. But what does that mean? What are some actual use-cases? I’m going to describe 4 practical examples of real-world event driven architecture.
Event Sourcing vs Event Driven Architecture
Event Sourcing is seemingly constantly being confused with Event Driven Architecture. In this blog/video I’m going through a popular blog post that explains various points that are very valid, however, they are conflating Event Sourcing with Event Driven Architecture. Event Sourcing is about using events as the state. Event Driven Architecture is about using events to communicate between service boundaries.
Securing Sensitive Data in an Event Driven Architecture
You secure sensitive data when stored in a database, but are you securing sensitive data in an event or message driven architecture? For example, if you need to include Credit Card information in a message for a queue to be processed. But need to be compliant with PCI-DSS! You can encrypt the actual message or a portion of the message, or if the broker supports it, use server-side encryption.
Should you use the Repository Pattern? With CQRS, Yes and No!
The repository pattern is polarizing. Some developers swear you should always use it to abstract data access logic while others think it’s unnecessary if you’re using an ORM. So should you use it? My answer is Yes and No! If you’re applying CQRS and Vertical Slice Architecture you’ll likely want a repository to build up Aggregates. However, for a Query, you may want to just get the data you need rather than an entire aggregate (or collection of aggregates) to build a view model.
Should you publish Domain Events or Integration Events?
Common advice is to not publish domain events outside of your service boundary. They should only exist within your service boundary. Instead, you should publish integration events for other service boundaries. While this general advice makes sense, it’s not so cut-and-dry. There are many reasons why you would want to publish domain events for other services to consume. Here are how I think of Domain Events and Integration Events and when to use them.
Event Sourced Aggregate Design: Focus on Business Logic
Separating data and behaviors can have a pretty profound impact on your design. An Event Sourced Aggregate allows you to focus on business logic by having capabilities to produce data (Events). Event Sourcing does exactly this by limiting the amount of state you require only to that needed for business logic within an Aggregate.
Refactoring to Value Objects
Value Objects are a part of Domain-Driven Design, and Julie Lerman and I cover them in our DDD Fundamentals course on Pluralsight. Even if you're not applying Domain-Driven Design to your application, you can take advantage of refactoring your business classes to avoid code smells like primitive obsession (follow the link for more on refactoring and code smells). To demonstrate this concept, I'm going to show a simple class as it might start out, and then show how I would refactor it. (This is actually based on a conversation I just had with one of NimblePros' clients. I figured I might as well share my thoughts more broadly than just with that team! The actual types have been changed, but the principles can be applied generally.)
Comparing Techniques for Communicating Between Services
In distributed software applications, different services or processes or apps frequently need to communicate with one another. Modern architectural trends toward microservices and containers and cloud-native apps have all increased the likelihood that apps will increasingly be deployed not as single monoliths, but as collections of related services. There are only so many different ways these applications can communicate with one another, and each choice brings with it certain benefits as well as consequences and tradeoffs. Let's consider the options and assess each one based on its relative performance, scalability, app isolation or independence, and complexity. Also, if you're interested in this topic, you may also want to read about how to apply CAP theorem (and PACELC) to microservices.
Why do we need Dapr?
I think its fair to say that "microservices" has established itself as the leading way to architect a modern distributed cloud-native application. I've discussed many of the advantages of this approach over "monolithic" architectures in my Pluralsight courses such as Microservices Fundamentals...
Domain-Driven Refactoring: Defactoring and Pushing Behavior Down
In the last post, we looked at our procedural handler and pulled behavior out that called to external services into its own domain service. This let our handler become more unit testable by creating a test seam, and we could now alter the behavior of the abstraction through mocks/stubs etc.
Domain-Driven Refactoring: Extracting Domain Services
In my last post, we looked at the Compose Method refactoring as a means of breaking up long methods into smaller ones, each with an equivalent level of granularity. This is the refactoring in my applications I tend to use the most, mainly because it's the simplest way of breaking up a hard-to-understand method.
What is CQRS?
What is CQRS? Traditional Software Development data models, which appear to indicate or infer that reads and writes are in synchronization when it comes to interacting with the database, in order to maintain the ACID( Atomicity, Consistency, Isolation, Durability) properties pertaining to the data.