Extensibility: A Strong Reason to Split a Large Service

One of the most important reasons to break down a large service into smaller ones is extensibility — the ability to add new functionality easily as the service context grows.

A Practical Example: Payment Service

Imagine you have a Payment Service responsible for handling payments and refunds using multiple payment methods, such as:

• Credit Cards.
• Gift Cards.
• PayPal.

Now the business decides to support additional payment methods:

• Store Credit from returns.
• Reward Points.
• Apple Pay or Samsung Pay.

The Problem with One Large Service

If all of this logic lives inside one large service, every time you add a new payment method, you are forced to:

• Re-test all existing payment methods, not just the new one.
• Re-deploy the entire service, including unchanged functionality.
• Deal with larger test suites and higher risk of regression.

This increases development time, raises risk, and makes it harder to introduce new payment methods quickly.

Splitting by Responsibility

Now imagine splitting that large service into smaller, focused services:

• Credit Card Processing Service.
• Gift Card Processing Service.
• PayPal Processing Service.

With this approach, adding a new payment method like Reward Points means:

• Developing only one new service.
• Testing only that service.
• Deploying it independently.

The Result

• Faster development.
• Smaller and more focused test scopes.
• Lower risk during deployment.

When Extensibility Is a Valid Reason

Use extensibility as a reason to split services only if:

• You are confident that new functionality will be added frequently in the future.
• Or the domain naturally evolves over time.

Examples

• Notification Service:
  It’s relatively rare to add new notification channels (SMS, Email, Letters), so keeping it as a single service often makes sense.

• Payment Processing:
  New payment methods are very likely to be introduced, so splitting services by payment type is a practical and scalable design choice.

Final Thought
Extensibility is not about splitting services prematurely — it’s about anticipating growth where growth is expected.

Design your services based on how the domain evolves, not just on how it looks today.