-
-
Notifications
You must be signed in to change notification settings - Fork 361
Handing off work
Typically, e.g. in web applications and application servers etc., you'll some time reach the limit as to how much it makes sense to process in a single request from a client.
In my experience, over time, requirements will accumulate on the form "when X happens, then Y should also happen", which - if you brute force implement these things, just makes the time it takes for your server to process a single request increase steadily over time.
As I see it, there's three problems with this:
- it makes your application suck, because it just takes longer and longer to process requests, the users will percieve the application to be slow and irresponsive
- you might get to a point where a server crash in the middle of a request will leave some side effects, even though any db transactions etc. weren't committed, e.g. if you're calling out to web services or generating files as part of handling the request
- there's an aesthetic problem as well: you'll most likely end up mixing all different kinds of bounded contexts together that would otherwise work independently if you were being true to the domain
Simple: Each time you process a request, you concentrate on serving that request. And then, all requirements on the form "when X happens, then Y should also happen" are implemented with publish/subscribe.
For example, when recording a purchase transaction, inside the PurchaseTransaction
you might see code like this:
public class PurchaseTransaction : FinancialTransaction
{
// (...)
public void Record()
{
// carry out some internal domain logic type of stuff here,
// and then:
DomainEvents.Raise(new DomainEvents.PurchaseTransactionRecorded(this));
}
}
which via Udi Dahan's immensely awesome domain events implementation will translate into a bus.Publish(new Finance.Messages.PurchaseTransactionRecorded( /* fill in relevant fields here */))
, allowing interested parties to (asynchronously) subscribe.
E.g. there might be a LetterService
listening to this event, which ensures that a receipt is generated and emailed to the customer when this happens, etc etc.
Basic stuff
- Home
- Introduction
- Getting started
- Different bus modes
- How does rebus compare to other .net service buses?
- 3rd party extensions
- Rebus versions
Configuration
Scenarios
Areas
- Logging
- Routing
- Serialization
- Pub sub messaging
- Process managers
- Message context
- Data bus
- Correlation ids
- Container adapters
- Automatic retries and error handling
- Message dispatch
- Thread safety and instance policies
- Timeouts
- Timeout manager
- Transactions
- Delivery guarantees
- Idempotence
- Unit of work
- Workers and parallelism
- Wire level format of messages
- Handler pipeline
- Polymorphic message dispatch
- Persistence ignorance
- Saga parallelism
- Transport message forwarding
- Testing
- Outbox
- Startup/shutdown
Transports (not a full list)
Customization
- Extensibility
- Auto flowing user context extensibility example
- Back off strategy
- Message compression and encryption
- Fail fast on certain exception types
Pipelines
- Log message pipelines
- Incoming messages pipeline
- Incoming step context
- Outgoing messages pipeline
- Outgoing step context
Prominent application services