• Service-oriented architecture (SOA) was an overused term and has meant different things to different people.
• SOA means that you structure your application by decomposing it into multiple services (most commonly as HTTP services) that can be classified as different types like subsystems or tiers.
  • The goal is business-agility and SOA achieves that by avoiding tight coupling and high cohesion.
• If your system belongs to a single bounded context, if it’s not big enough then all you have to do to fix things up is to decompose your system into modules the right way.
• Otherwise, you need to introduce way more autonomous and isolated concept that we can call a service.
• Service has logical boundaries, not physical.
  • It can contain any number of physical servers which can contain both the backend code and UI data.
  • There can be any number of databases inside those services, and they all can have different schemas.

Wrong Service Boundaries Identification

Entity-Services

• Splitting a system to entity-services is an approach encountered so often that it’s called an anti-pattern.
• Sometimes this approach is accounted for an obsession with reuse: all stuff related to some entity in a single place, 100% reusable, pure bliss!
• But code reuse, when considered as a primary motivational force, is a fallacy.
  • The same concept goes for services.

Drawbacks

1. Tight Coupling: Every service is a client of all the rest ones.
   • So if one service changes, you have to test the whole system.
2. Chatty Services: They have a lot of internal communication — usually synchronous, which is fragile and slow.
3. Lots of services: Hence it’s hard to comprehend overall picture and hard to track a request.
4. Poor encapsulation: Business-rules are spread all over the system.
   • Typically, each client has some checks before updating some other service’s data.
   • This update is carried out with pure update query, so data and behavior are torn apart.
5. Synchronous nature: Typically, it’s http, and every call is synchronous.

Blind Mapping of Blurred Business Architecture to Technical Architecture

An approach I encounter very often goes like “Why bother? We’re here for writing code and shipping stuff, let’s just do it!”. Well, it works for a small project, and it doesn’t in a bigger one. It inevitably brings you to business-IT impedance, which results in decreasing business-agility. And if you’re not agile, you’re out.

Here is how technical architecture not aligned with business functionalities looks like:

• There are two problems highlighted here.
  • Since there are many business functionalities inside a boundary, chances are they would have different development pace, different scalability and availability requirements.
    • It would be hard to split them, which leads to tight coupling.
    • When the new requirements arise within this gap, those two technical services will be coupled very tightly.
  • There is a gap between technical services.
• This antipattern is confidently leading in terms of drawbacks amount.

Drawbacks

• Synchronous communication is resource-intensive:
  • Service receiving a request waits for the second service, which waits for the third one and so on.
• Expensive scaling: You need to scale everything instead of the services that really need it.
• It’s not reliable: If only one service is down then the whole system is down.