DEV Community: Derek Comartin - CodeOpinion

Event Choreography for Loosely Coupled Business Processes

Derek Comartin - CodeOpinion — Wed, 13 Jul 2022 23:27:00 +0000

What's Event Choreography? Let's back up a bit to answer that. Event Driven Architecture is a way to make your system more extensible and loosely coupled. Using events as a way to communicate between service boundaries. But how do you handle long-running business processes and workflows that involve multiple services? Using RPC is going back to tight coupling, which we're trying to avoid with Event Driven Architecture. So what's a solution? Event Choreography

Join!

Developer-level members of my YouTube channel or Patreon get access to a private Discord server to chat with other developers about Software Architecture and Design as well as access to source code for any working demo application that I post on my blog or YouTube. Check out the YouTube Membership or Patreon for more info.

Follow CodeOpinion

Twitter
YouTube

SOLID? Nope, just Coupling and Cohesion

Derek Comartin - CodeOpinion — Wed, 13 Jul 2022 20:12:01 +0000

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.

YouTube

Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything in this post.

youtube.com

Coupling and Cohesion

With over 20 years of professional software development experience, I’m mostly thinking about coupling and cohesion as a guide to software design. I’m not explicitly thinking about SOLID principles or clean architecture.

Coupling and cohesion are like the yin-yang of software design. They push and pull against each other. You’re striving for high cohesion and low coupling, however, you’re trying to find a balance. We’re always fighting against coupling.

There are many different forms of coupling but to narrow it down for simplicity’s sake:

“degree of interdependence between software modules”

ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary

At a micro level, this could be the interdependence between classes or functions, and at the macro level, this could be the interdependence between services.

When you’re thinking about spaghetti code you’re likely actually referring to a system that has a high degree of coupling at the macro and micro levels. This makes changes difficult to make or they break other parts of the system because there’s a high degree of coupling. Check out my post on Write Stable Code using Coupling Metrics for more on coupling.

Cohesion refers to:

“degree to which the elements inside a module belong together”

Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design

You can look at cohesion both from a micro and macro level. From a micro level, this can be viewed as how do all the methods relate in a class? Or how do all the functions of a module relate? From a macro level, how do all the features relate to a service? Check out my post on Highly COHESIVE Software Design to tame Complexity for more on cohesion.

But what does “belong together” mean? For me, this is about functional cohesion. Grouping-related options of a task. Not grouping based on data (which is informational cohesion). Yes, data is important, however, data is required by the functionality that is exposed.

Business Capabilities

Speaking of functionality, let’s jump to the Single Responsibility Principle for a second as this might clarify why functional cohesion is important.

When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person , or rather, a single tightly coupled group of people representing a single narrowly defined business function. You want to isolate your modules from the complexities of the organization as a whole, and design your systems such that each module is responsible (responds to) the needs of just that one business function.

https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

This might seem a bit more clear how the single responsibility principle at its root addresses coupling and cohesion.

If we focus on business capabilities and group them together, we’ll end up with a service. That’s why I always define a service as:

A Service is the authority of a set of business capabilities.

At a macro level, we’re trying to have a high degree of cohesion by grouping by business capabilities. Behind those capabilities is data ownership.

Unfortunately, many are still focused purely on data and what I call “entity services”. This was a screenshot from a post on Reddit. The question was if this data model diagram should be implemented as a service per “entity”.

This type of thinking is based on informational cohesion, not functional cohesion. The focus solely on data and not thinking at all about functionality and behavior leads to design generally around CRUD.

As an example, you’ll often have “Manager”, and “Repository” classes that look similar to this.

The Product “entity” is really just a data model with a bunch of properties. There is no behavior exposed, they are just data buckets.

So where is the actual functionality of a product? In a large system, for example in a distribution domain, a product isn’t just a product.

A product means different things to different people within that domain.

Sales are thinking about the Sale Price of a product and are customer-centric. Purchasing/Procurement is thinking about the cost and is vendor centeric. The warehouse is concerned about shipping and receiving. They all have different business capabilities, and because those capabilities are different, they care about different data behind those capabilities.

A product isn’t just a product that has to live within a single boundary. It’s a concept that can live within multiple different service boundaries.

Organizing related business capacities (features) into services allows us to decide how we want to handle technical concerns within each service or to a specific feature. Dependencies shared concerns such as data access, validation, etc. All of these decisions can be localized and made per service.

Loose Coupling

So you’ve defined boundaries based on functional cohesion, but they must have some interdependence between each other?

Having a free for all where any service can be coupled to any other service is still a hot mess of spaghetti. In other words, tight coupling. The system will still be hard to change and fragile to change.

You want to remove the tight coupling by having service boundaries be independent and not directly coupled to other services. One way of achieving this is through loose coupling provided by messaging.

Because you’re grouping by business capabilities, and the data behind those capabilities, each service should have all the data it needs. This means that you aren’t coupling services because you need to fetch data from them to perform an action.

Services together need to create workflow and exchange information. As an example from the diagram above, if the Warehouse has a “Quantity on Hand”, you might think that Sales would need that so it knows if it can sell a given product. However, Sales actually has its own concept called ATP (Available to Promise) which is a business function that is the projected amount of inventory it can sell. This consists of what’s in stock in the Warehouse, not allocated existing orders (Invoicing), as well as purchase orders and expected receipts (Purchasing).

Sales can maintain their ATP by consuming events from other services. It does not need to make directly coupled to an API to make calls at runtime to calculate ATP for a given product. It maintains and owns the ATP for all products based on events it’s consuming that are published from other services. When Invoicing publishes an OrderInvoiced event, it can subtract an amount from ATP. If the warehouse does a stock count and publishes an InventoryAdjusted event, Sales will update the ATP accordingly.

Responsibility

From a lower-level code perspective, the coupling can be challenging when we have to deal with many different technical concerns. Web, Authorization, Validation, Data Access, and Business Logic. But as mentioned earlier, each feature/capability can define how each of these concerns is handled.

While you can share between features, such as a domain model, this naturally starts limiting the coupling between a set of features.

One approach to handle the common concerns is by using the pipes & filters pattern. Specifically, the Russian doll model which the request passes through a filter that can call (or not) the next filter. This allows you to separate various concerns and create a pipeline for a request.

For more check out my post on Separating Concerns with Pipes & Filters

Coupling and Cohesion

Building a large system without any boundaries (low cohesion) and a high degree of coupling is ultimately building a big turd pile of a system.

It will be hard to add new functionality, and hard to change existing functionality without breaking and causing regressions.

Focusing on having highly cohesive services that provide specific business capabilities and loosely coupling between those services to provide workflow and business processes will allow you to build a system that is more resilient to change.

Decomposing a large system into smaller independent logical service boundaries allows you to make different decisions that are localized to an individual service. No system will be perfect, especially over time and it will need to evolve. Focus on coupling and cohesion as a guide.

Join!

You also might like

Follow CodeOpinion

Twitter
[YouTube]

The post SOLID? Nope, just Coupling and Cohesion appeared first on CodeOpinion.

What is Software Architecture?

Derek Comartin - CodeOpinion — Wed, 06 Jul 2022 21:40:30 +0000

Software architecture is about making key decisions that will impact how you can make decisions in the future. It's about giving yourself options at a relatively low cost early on so that your system can evolve over time without a high cost. Software architecture is about options.

Join!

Follow CodeOpinion

Twitter
YouTube

Avoiding Batch Jobs by a message in the FUTURE

Derek Comartin - CodeOpinion — Wed, 29 Jun 2022 21:59:46 +0000

Some people will call it cron jobs, scheduled tasks, or batch jobs. Whatever you call it, it’s a process that runs periodically looking at the state of a database to determine some specific action to occur for the various records it finds. If you’ve dealt with this, you probably know it can be a nightmare, especially with failures. And of course, these usually run in the middle of the night, so get ready for a page!

YouTube

Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything in this post.

Reservation

A while back I placed an online order at a big box store that was set for pick-up at the store, rather than delivery. Here’s the confirmation order:

Note that the email says, once my order is ready for pick-up I’ll get an email. This is because an employee at the store has to physically go to get the item off the shelf somewhere in the store, and then bring it to a holding area for pick-up orders.

Once the item is taken from the shelf by the employee at the store, they set the order as being available for pick-up, which triggers this email I received:

The interesting part of this email is that it says I have 7 days to pick up my order, otherwise I’ll be refunded and the item will be put back onto the shelf.

Basically, this is a reservation. For more on the Reservation Pattern, check out my post on Avoiding Distributed Transactions with the Reservation Pattern.

Timeline

There are a couple of different scenarios. The first is that I actually drive to the store and pick up the item that I ordered.

The timeline would be that I placed my order, sometime later the order was reserved (taken from the shelf by an employee), and then later I arrived at the store to complete my reservation/order.

The second scenario is that I place my online order, it’s reserved for me, but I just never show up to pick the item up at the store.

After 7 days from the order being reserved, the reservation will expire, which means an employee will take the item and put it back on the shelf so someone else can purchase it.

Batch Jobs

If you’re using batch jobs, how would that work? Typically you’ll have a process that runs every day that will look at the state of the database and then determine what to do. In this example, this might be selecting all the orders that are reserved but have not yet been completed.

At this point, the batch job has to do all of the refunds to credit cards and update the database to set the orders as canceled.

The issue with batch jobs is that they are done in a batch. If there are 100 orders that have expired, the batch job iterates one by one performing these actions. What happens if at order 42 of 100 the process fails, because of a bug or failing to connect to the payment gateway, etc.

Batch jobs, purely based on the name or not done in isolation. This means the entire batch fails. Typically batch jobs are run during off-peak hours, which is usually in the middle of the night. If it fails in the middle of the night, you’re likely to get a page/alert of the failure.

Isolation

Rather what we would want is to handle each individual expired order/reservation in isolation. What we want to do is tell the system in the future, as a reminder, to cancel the reservation/order in 7 days when it’s reserved.

If the customer doesn’t come and pick up the item at the store, then the “expire reservation” reminder will kick in and execute at the appropriate time, which is 7 days from when the order was reserved.

However, if the customer does come and pick up the item at the store which completes the order, the “expire reservation” will still be triggered, however, it won’t need to do anything since the order is complete. It can exit early and not perform any action.

Each Order will have its own “expire reservation”. Each is executed exactly 7 days from when the order was reserved and each will be executed in isolation. If one fails, it doesn’t affect the others.

Delayed Delivery

So how can we technically implement this type of future reminder? You can use a queue that supports delayed delivery.

When sending a message to a queue, you’re also going to provide the queue with a period of time to delay the delivery to a consumer.

This means that the queue will not make the message visible to consumers. Consumers will not be able to pull this message from the queue until the delay period of time has elapsed. The consumers won’t even see the message in the queue.

Once the delayed delivery period has elapsed, the message will be visible again.

The consumer will then pull the message and process it.

What this allows us to do is send a message to be processed in the future.

In the example of our online order, this means that once an Order is reserved and the item is taken from the shelf, we enqueue a “expire reservation” message with delayed delivery of 7 days. After the 7 days, we will process that “expire reservation” message. If the order is already completed, the process just exits early. If it hasn’t been completed, it then does the credit card refund and updates the database to set the Order as canceled.

Avoiding Batch Jobs

You can avoid batch jobs and have smaller units of work in isolation by telling your system to do something in the future. Leveraging a queue that supports delayed delivery is one example of how you can accomplish this.

The workload will be smoothed out across time and provide isolation so you can handle failure at an individual level of work.

Join!

You also might like

Follow CodeOpinion

The post Avoiding Batch Jobs by a message in the FUTURE appeared first on CodeOpinion.

Should you Delete or Soft Delete?

Derek Comartin - CodeOpinion — Wed, 29 Jun 2022 14:34:18 +0000

Should you delete records from your database or instead use a soft delete? I was recently asked my view on this question from a follower on Twitter. So what's my answer? Well I'm not usually thinking about "deleting" anything. Rather I'm thinking about adding.

Join!

Follow CodeOpinion

Twitter
YouTube

Where should you use gRPC? And where NOT to use it!

Derek Comartin - CodeOpinion — Thu, 23 Jun 2022 16:21:04 +0000

I've recently read a few blogs and watched some videos that compare gRPC with REST as well as GraphQL. It seemed like the majority make the claim that gRPC is the standard for communication between services without giving any real reason why. What I think would be better served is explaining where and the situations where gRPC could be useful and where I'd avoid using it.

Join!

Follow CodeOpinion

Twitter
YouTube
Newsletter

Sidecar Pattern for Abstracting Common Concerns

Derek Comartin - CodeOpinion — Wed, 22 Jun 2022 21:50:41 +0000

What is the sidecar pattern? Applications and services often have generic concerns such as health checks, configuration, metrics, as well as how they communicate with each other either directly or through messaging. Services usually implement these using libraries or SDKs to handle these concerns. How can you share these concerns across all these services so you’re not implementing them in every service? The sidecar pattern and ambassador pattern might be a good fit to solve this problem.

YouTube

Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything in this post.

Shared Concerns

Regardless of the platform, you’re going to leverage libraries/packages/SDKs to handle common concerns like health checks, configuration, metrics, and more. Each service will have these common concerns and need to use the libraries for their respective platform.

For example, if you had two services, one written in .NET and the other written in Go. Each service would leverage libraries in its ecosystem to provide this common functionality.

Even with libraries, you still need to define how you’re handling and dealing with these common concerns. You may be using the same underlying infrastructure for both of them. As an example, each service might be publishing metrics to Cloudwatch.

Wouldn’t be nice if there was a standardized way that each service would handle these shared concerns?

Sidecar pattern

The sidecar pattern allows you to extract the common concerns from your service and host them separately in a separate process, known as a sidecar.

In the containerized world, this is often thought of as a separate container from your service, however, it really is just a separate process that runs locally alongside your service.

With a sidecar, your service can now interact with a separate process that will handle the common concerns. The sidecar can perform health checks on your service, your service can send metrics to the sidecar, etc.

Ambassador Pattern

Back to the example of sending metrics to Cloudwatch. With the sidecar, we can also apply the Ambassador Pattern. This all makes the sidecar a proxy to send data to Cloudwatch. This means our service is interacting with the sidecar, using a common API, and it’s in charge of sending the data to Cloudwatch. It’s not just metrics and Cloudwatch, this applies to any external service.

The benefit is that the sidecar is handling any failures, retries, backoffs, etc. We don’t have to implement all kinds of retry logic in our service, rather that’s a common concern handled by the sidecar when communicating with external services.

If we want to make an HTTP request to an external service, we proxy it through the sidecar.

If there is a transient failure, the sidecar is responsible for doing the retry while still maintaining the connection to our service while it does so.

Abstraction

While each service has its own instance of a sidecar, you can be using the same sidecar for many different services. This allows each service to have the exact same interface to all of the shared concerns the sidecar provides.

This means that you can also be using it for things like a message broker.

If you read any of my other blog posts or watch my videos on YouTube, you know I’m an advocate for loosely coupling between services using messages, and not using blocking synchronous request-response.

A sidecar can provide a common abstraction over a message broker. This means that each service doesn’t have to interact with the broker directly, nor does it need to use the specific libraries or SDKs for that broker. The sidecar is providing a common API for sending and consuming messages and is abstracting the underlying message broker.

This means you could have one service using .NET and another using Python, both exchanging messages to a broker supporting AMQP. Each service would be completely unaware of what that underlying transport and message broker is.

Trade-offs

So why would you want to use a sidecar and ambassador patterns? If you have services that are using different languages/platforms, and you want to standardize common concerns. Instead of each service implementing using their native packages/libraries/SDKs to their respective platform, the sidecar pattern allows you to define a common API that each service uses. This allows you to focus more on what your service actually provides rather than common infrastructure or concerns.

One trade-off to mention is latency. If you’re using a sidecar with the ambassador pattern to proxy requests to external services, a message broker, etc, you’re going to be adding latency. While this latency might not that much, it’s something to note.

If you don’t have a system that’s comprised of many services, or they are all using the same language/platform, then a sidecar could just be unneeded complexity. You could leverage an internal shared package/library that each service would use for defining a common API for shared concerns, it doesn’t need to be a sidecar. Again, your context matters. Use the patterns when you have the problems these patterns solve.

Join!

You also might like

Follow CodeOpinion

Twitter
YouTube
Newsletter

The post Sidecar Pattern for Abstracting Common Concerns appeared first on CodeOpinion.

Build Asynchronous Systems! The world is full of Asynchronous Workflows

Derek Comartin - CodeOpinion — Tue, 21 Jun 2022 14:42:33 +0000

The world is asynchronous. A lot of the workflows and business processes you encounter out in the world are long-running and driven by asynchronous systems.

Yet as developers, we're still often writing procedural and synchronous code to model these business processes. I'm going to give one of my favorite examples of a going out to eat at a restaurant to illustrate this and how this can be applied in software.

Does a Data Access Layer make it easier to change your Database?

Derek Comartin - CodeOpinion — Wed, 15 Jun 2022 17:09:09 +0000

One primary reason for a data access layer or abstraction is your ability to move underlying databases easier. Have you ever replaced the underlying database of a large system or service? For example, moved from one relational database like PostgreSQL to MySQL. Or perhaps went from a relational database to a document or event store?

There seem to be two groups of people. Those that have will say that abstracting the underlying database is crucial. While the other group never has moved database and question abstracting or creating a data access layer because you likely won't replace the database.

For me, like many things in software architecture, it's about coupling. If you limit coupling this isn't much of a hot topic.

Why use DTOs (Data Transfer Objects)?

Derek Comartin - CodeOpinion — Wed, 13 May 2020 23:13:03 +0000

Should you really use DTOs (Data Transfer Objects)? Seem like a lot of work mapping your database entities to another object? Why Bother? The simple answer is coupling.

Data Transfer Objects

First, what are DTOs? When people refer to Data Transfer Objects, what they mean are objects that represent data structures that generally do not contain any business logic or behavior. If they do contain behavior, it’s generally trivial.

Data Transfer Objects are often used to be serialized by the producer and then deserialized by the consumer. Often times these consumers may live in another process being used by an entirely different language and/or platform.

YouTube

I’ve recorded a short video explaining this with some sample code. Check out the video and make sure to subscribe to my YouTube Channel.

Crossing Boundaries

The most common example of this is creating an HTTP API using ASP.NET Core that returns an object from its Controller actions that are ultimately serialized to JSON. The consumer is oftentimes JavaScript that uses those JSON responses in displaying the browser using a Component or SPA Framework.

Internals

If you’re not using DTOs, then you’re likely exposing internal data structures.

The biggest culprit of this is simple TODO demo applications that expose the database entities directly. Meaning they output a serialized list of TODOs to the javascript frontend. And when you want to create a new record, they often times take the TODO object to insert directly into the database. This is leaking internals.

This is my biggest complaint with simple demo applications are they often don’t implement or follow some practices, because rightly so, they aren’t applicable to a simple TODO application. However, people take the example of a simple TODO and use the same patterns into a much large application.

The problem is when internal data objects are serialized and consumed by a client you either down own or cannot change easily. Or, which happens more often, the application itself gets very large.

Contracts

The moment you want change internal data objects, you now have to update the clients.

Take this simple example of a Customer that is an internal data structure we use through the system and likely use to persist using an ORM.

View the code on Gist.

If we are serializing this structure and clients are consuming this, if we change this structure, we’re likely going to break out clients.

View the code on Gist.

This change would require a change to all of our clients. We could easily make this change in our own codebase and have all our own usages be correct, but we would be breaking all of our decoupled clients that get a serialized representation.

Representation

When creating an HTTP API, it’s all about representations. Most often times clients need a rich representation of a resource, not a just serialized version of a database entity. They often times need related data.

Having your API return rich representations means you must do some level of composition to create an object, not just a database entity, that will get serialized. This is where a DTO comes into play.

I actually don’t often use the term DTO, but rather use the word Representation or ViewModel. The purpose is still the same, it’s a data structure that is a contract between the producer and the consumer. That contract should remain stable (through backwards compatibility) or have a versioning strategy.

Coupling

The reason you want to use DTOs is that you want clients to couple to that contract, not to your internal data structures. This allows you to modify and evolve your internals freely without breaking clients.

Links

Follow @codeopinion(function() { window.mc4wp = window.mc4wp || { listeners: [], forms: { on: function(evt, cb) { window.mc4wp.listeners.push( { event : evt, callback: cb } ); } } } })();

  <div>
    <div>
      <h2>Enjoy this post? Subscribe!</h2>

      <p>Subscribe to our weekly Newsletter and stay tuned.</p>

      <div>
        <span>
          <i></i>
        </span>
        <input type="text" name="EMAIL" placeholder="your@email.com">
      </div>

      <input type="submit" value="Subscribe">

    </div>    
  </div>
  <div>      
  </div>
</div>

Leave this field empty if you're human:

The post Why use DTOs (Data Transfer Objects)? appeared first on CodeOpinion.

Message Properties

Derek Comartin - CodeOpinion — Thu, 05 Dec 2019 02:45:46 +0000

Over the years I’ve learned various aspects of messaging either through using various products, reading other blogs, or unfortunately in a lot of cases, discovering them myself. One of those aspects is message properties.

Specifically, (meta) data that you might want to include in your messages to solve some common problems.

My plan is to dive deeper with implementation examples for each topic listed in this post. Hopefully, this post can serve as a reference point to your adventures in messaging or possibly gain some insight that provides a solution for a pain point you may (already) be experiencing.

I was inspired to write this post after seeing this tweet:

Savvas Kλeanthous 🇬🇧🇪🇺🇨🇾

@skleanthous

When messages are transmitted they should include at minimum:
1. Message name
2. Name of service which owns the contract of the message
3. Message version
4. Message unique id
5. Correlation id
6. Causation id
7. UTC Timestamp

[1 of 5

21:55 PM - 20 Nov 2019

102 287

Type/Name

The naming of messages is incredibly important for a variety of reasons. When talking about events, it’s important to name them in the past tense because it conveys that they are statements of fact.

Most often the name of an event is used to determine how to deserialize into a specific type. Where I’ve personally run into problems, in .NET specifically, is using the CLR type name as the event name to determine how to deserialize. The issue with this is you’re very likely to change the name of your CLR type.

Prefer to having a static name for an event and not using the CLR type name at runtime to create the event name.

Message Version

Most often when needing to version a message is to simply create a new type/name. With events, I think this approach works fairly well when you discover a better way to describe the event and along with it the data to expose.

When a new event isn’t required, but rather a slight change in data is to specify the version in the message. Consuming clients can use the message name along with the version to determine how to process the body of the message.

Message ID

A unique identifier of a message. This can be used for idempotency and concurrency. Message Handlerscan keep track of which messages IDs they have processed and determine if they should act upon receiving a message.

This is important because message handlers should be reentrant and messages can be delivered more than once.

Correlation ID

A unique identifier that allows you to reference the flow of events (event chain) or a transaction. Also, often called a Trace ID. Assigning a correlation ID as soon as possible and any message handler that receives a message with a correlation ID then uses that same ID for any messages it outputs.

This is very useful for logging and error handling in asynchronous and distributed environments.

Contract Owner

Who owns the message contract can be important. Depending on how messages are distributed, there may be many messages from various owners. Knowing who owns a message contract is helpful for troubleshooting as well as how to handle that message.

An OrderPlaced event seems like it could be unique across all services, however, in a distribution domain, is that a Sales OrderPlaced from the Sales service or a Purch OrderPlaced from the purchasing service?

Having the owner of the message provides the ability to distinguish how to handle the message when the name alone doesn’t provide enough distinction.

UTC Timestamp

This seems obvious but it gives more context to when the message was created. A useful is keeping track of latency between a message being created to how long it’s taking a given service to process it.

Sender

Who originated the message. Not the service, but rather the user. This could be an access token that is then used to determine if the sender has the correct permissions or is authorized to perform the given request.

Resource/Entity Version

The version of the resource/entity that you are performing an action on. Similar to the message ID this can be used for concurrency. A wonderful example of this is Azure Cosmos DB which uses an ETag as the resource version which is then used with an If-None-Match header for optimistic concurrency. If you’re using Cosmos DB check out my post on Optimistic Concurrency in Azure Cosmos DB

Message Properties

I’ll be going in-depth in each of the above topics with code examples for the actual implementation of how you would use these message properties. Stay tuned.

If you’d like to add to the list, let me know in the comments or on Twitter.

Follow @codeopinion

The post Message Properties appeared first on CodeOpinion.

Roundup #58: Orleans 3.0, Snitch, What’s Your Problem? Next 5 years of ASP.NET Core

Derek Comartin - CodeOpinion — Fri, 08 Nov 2019 00:49:17 +0000

Here are the things that caught my eye recently in .NET. I’d love to hear what you found most interesting this week. Let me know in the comments or on Twitter.

Follow @codeopinion

Introducing Orleans 3.0

We are excited to announce the Orleans 3.0 release. A great number of improvements and fixes went in, as well as several new features, since Orleans 2.0. These changes were driven by the experience of many people running Orleans-based applications in production in a wide range of scenarios and environments, and by the ingenuity and passion of the global Orleans community that always strives to make the codebase better, faster, and more flexible. A BIG Thank You to all who contributed to this release in various ways!

I was happy to see the generic host for co-hosting with something like ASP.NET Core. I’ve blogged Co-Hosting Orleans and ASP.NET Core which this about this feature.

Link: https://devblogs.microsoft.com/dotnet/orleans-3-0/

Snitch

A tool that helps you find transitive package references that can be removed.

> snitch Foo.csproj --tfm net462

Building Foo (net462)...

Building Bar (netstandard2.0)...

Building Baz (netstandard2.0)...

The following packages can be removed:

Autofac (ref by Baz)

Newtonsoft.Json (ref by Bar)

The following packages might be removed:

Castle.Core (ref by Baz) 4.4.0 <- 4.3.1 (Baz)

Link: https://github.com/spectresystems/snitch

What’s Your Problem?– Asbjørn Ulsberg

A talk given by Asbjørn Ulsberg from PayEx at the 2019 Platform Summit in Stockholm.

An API isn’t stronger than its weakest link and what’s often ignored in the ongoing maintenance and development of an API is the constant effort required to provide great self-servicable error messages. What this means is that without great, user-friendly error messages, your API is not going to be great.

Just think about your first interaction with an API. How many failing requests have you sent before you have dug yourself through swathes of error messages and documentation to get to that one penultimate successful request making your heart sing and fists shaking in the air?

Great error messages make them not feel like errors, but like friendly guidance towards a working request. They should be detailed enough to let the developer fix whatever problem there is themselves, like a dialogue between a customer and a support technician.

This talk will give you ideas of how to handle errors and exceptions that occur in your application, be it with the incoming request, database failures or errors received from a 3rd party and how to serialize them into user friendly and actionable problem messages.

Link: https://www.youtube.com/watch?v=ZWIUn5BHDBc

The next 5 years of ASP.NET Core – Ryan Nowak

Join Ryan Nowak on a tour of ASP.NET Core’s evolution from “Project K” to present day and look forward to a few possible futures. We’ll discuss technical design details of how the ASP.NET Core stack is changing from bottom (hosting and startup), through the server, middleware pipeline, and up to high-level frameworks like MVC and Blazor.

This is a technical deep-dive talk, and will explore possible design directions of .NET 5 and future releases.

Link: https://www.youtube.com/watch?v=7dJBmV_psW0

Follow @codeopinion

The post Roundup #58: Orleans 3.0, Snitch, What’s Your Problem? Next 5 years of ASP.NET Core appeared first on CodeOpinion.

DEV Community: Derek Comartin - CodeOpinion

Event Choreography for Loosely Coupled Business Processes

Join!

Follow CodeOpinion

SOLID? Nope, just Coupling and Cohesion

YouTube

Coupling and Cohesion

Business Capabilities

Loose Coupling

Responsibility

Coupling and Cohesion

Join!

You also might like

Follow CodeOpinion

What is Software Architecture?

Join!

Follow CodeOpinion

Avoiding Batch Jobs by a message in the FUTURE

YouTube

Reservation

Timeline

Batch Jobs

Isolation

Delayed Delivery

Avoiding Batch Jobs

Join!

You also might like

Follow CodeOpinion

Should you Delete or Soft Delete?

Join!

Follow CodeOpinion

Where should you use gRPC? And where NOT to use it!

Join!

Follow CodeOpinion

Sidecar Pattern for Abstracting Common Concerns

YouTube

Shared Concerns

Sidecar pattern

Ambassador Pattern

Abstraction

Trade-offs

Join!

You also might like

Follow CodeOpinion

Build Asynchronous Systems! The world is full of Asynchronous Workflows

Does a Data Access Layer make it easier to change your Database?

Why use DTOs (Data Transfer Objects)?

Data Transfer Objects

YouTube

Crossing Boundaries

Internals

Contracts

Representation

Coupling

Links

Message Properties

Type/Name

Message Version

Message ID

Correlation ID

Contract Owner

UTC Timestamp

Sender

Resource/Entity Version

Message Properties

Related

Roundup #58: Orleans 3.0, Snitch, What’s Your Problem? Next 5 years of ASP.NET Core

Introducing Orleans 3.0

Snitch

What’s Your Problem?– Asbjørn Ulsberg

The next 5 years of ASP.NET Core – Ryan Nowak