People

Domain

Software

Don't call The Others

Scheduling

• A loooong business process
• Half a year before the date
• Done upfront

Selling tickets

• High volumes
• Based on the schedule
• High volumes

Architecture

Tickets => Scheduling

Don't call The Others

• A dependency on the external system
• The dependency is synchronous
• The data are changing infrequently.

How not to call The Others (1)

• Make a local copy of data.
• Use local copy.
• It's not a cache - it's an explicit copy.
• Publish schedules' changes.

How not to call The Others (2)

• Provide an API for polling.
• Publish using messaging.
• Provide an ATOM feed with events.

How not to call The Others - summary

• Don't call the others :)
• Reason on your data, not the others.
• Make implicit (cache) explicit (copy).

Haven't I seen it before?

Notifications

• Many possible channels (email, sms).
• Commands send after an event to the notification service.
• Commands sent asynchronously.

Architecture

							
_.On(TicketBought e => Send(GetBody(e)))
							
						

Haven't I seen it before?

• Commands are issued multiple times.
• There's no exactly-one delivery.
• No transactions between services.

How to see it exactly once

• Make receiver idempotent.
• Include unique identifier in a command.
• Check if it was dispatched.

Is it me?

Employees

• A registry for employees
• Every employee has an identifier
• Not everyone is a user

Users

• Identity management
• Every user has an identifier
• Not everyone is an employee

Architecture

							
employee.UserId = null;
user.EmployeeId = null;
							
						

How to be me? (1)

• Same id value - different meanings.
• What if we used Guid?
• What if used the same id if needed in other services?

How to be me? (2)

							
employee.Id == user.Id; // same entity in two services
							
						

Ids in composite UIs

• Combining services on the client side.
• Same id - multiple services.
• You may generate ids on the client side.