Service Oriented Architecture – Basics

The Service Oriented Architecture (SOA) is not a technology instead it is a collection of Services. Precisely it is an architectural style for building business applications using loosely coupled services which communicates with each other.

SOA      =    Messages + Services

Services – Self-contained business functionality and communicate using messages.

Messages – It is a discrete unit of communication.  It should be cross-platform, secure, asynchronous, reliable, follow industry standard and able to describe and discovery service.

The SOA shifts your thinking from classes and objects to messages.

The webservice is nothing but a service available over the web (Or method of communication between two devices over a network) while API (Application Programming Interface) acts as an interface between two different applications so that they can communicate with each other. The API may or may not be web-based.  Having said that all the all the web services are APIs but all APIs are not web services. The webservice always needs a network while for API it may/may not be needed.

WebServices are mainly of two types

  1. SOAP
  2. RESTFul

Let’s understand the differences between SOAP and REST

  1. SOAP stands for Simple Object Access Protocol. REST stands for Representation State transfer.
  2. SOAP is an XML based protocol which uses WSDL for communication between source and recipient. REST is an architecture style protocol which uses XML and JSON to communicate between consumer and provider.
  3. SOAP uses RPC while REST directly uses URL.
  4. The transfer is over HTTP, FTP, SMTP and other protocol for SOAP while for REST it is HTTP only.
  5. SOAP is hard to implement over REST.
  6. The performance is slower compared to REST.
  7. SOAP is more secure since it does define its own security. The REST is less secure. The transport defines the security. (Smart consumer and provide while dumb pipe).

The SOAP message is large.  The core element of SOAP message is a SOAP envelope. The SOAP envelope defines the start and end of the message. It has two parts 1. SOAP HEADER 2. SOAP BODY

WSDL – Web Service Description Language

The WSDL is an XML based interface that is used to describe the functionalities of the webservices .

Bloated Domain Objects And CQRS (Command, Query Responsibility Segregation)

Problem of Bloated Domain objects

In business software applications, the domain objects (entities) are used to represent the business domain. As the application grows and adds more business logic, the service layer, mappers and other patterns gets applied. Often this leads to domain object becomes bloated and the related components become huge & un-maintainable.

CQRS solves the common problem of having a bloated Domain objects. The domain objects get bloated largely because of bounded context. The series of contexts which makes developers think that a single domain object is sufficient to handle all the related things. For example, a large Invoice object for handling Invoice, Shipment and handling change of address for customer . But in reality, these contexts (invoicing, shipment and change) need not be related to same Invoice entity.

What is Command, Query Responsibility segregation (CQRS)?

In order to simplify the Domain objects, CQRS proposes to have two types of domain entities.

  • those serving the command (ordering/assertion services)  – For example, SaveCustomer, CreateInvoice, ShipProduct etc
  • those serving a Query (request) – examples include GetCustomerAddress, SearchCustomer etc

With this separation, the complexity (number of fields, methods) of entities used becomes simplified. And hence the Data mapper layers & the service layers becomes more simplified.

Where can I use CQRS?

  • Largely complex system: Applying CQRS on a simple CRUD operation based system is a over kill. When there is a domain heavy system, like banking and financing systems, LOB applications where business logic, lots of boundary conditions are heavy. Where it makes DDD (Domain driven design) provides high value.
  • Situations where you will apply Microservices, Eventual consistency and Event Sourcing. When we have separation of concerns using CQRS, the microservices becomes much simpler to design and maintain. With Event sourcing we are focused on getting the data (query) from other related sources and is what CQRS propagates.

Final words

CQRS is a carefully thought out pattern for simplifying large and complex systems. And it should not be applied for simple green field applications. Do let me know what you think.

Micro-Services, Eventual Consistency and Event sourcing patterns

Microservices is a really becoming a famous architectural pattern that most of the new software written these days, just apply them. One of the most important differentiation between the traditional web services and micro-services pattern is the amount of common stuff across different subject areas. This calls for a discussion on how Eventual Consistency pattern is mandatory for successfully implementing microservices.

The micro frontend if gaining lots of popularity.  You can read about microservices principles and micro frontends at

Microservices and Microfrontends

Micro-Service Pattern

Generally, in a micro-service pattern, the API’s are split into small subject areas. For example for a CRM application, the subject areas are

  • Customer information – like name, address, email, phone
  • Appointment information – which customer, salesperson, when, where
  • Relationship management – sales/manager, what products, interests
  • Campaign data – offers, deals etc

Then micro-services are built for each of the subject areas.  The microservices are logically and physically separated from each other. ie there is no sharing (code, database, component etc) between any of these micro-services of these subject areas. Pictorially its looks something like this.

Applying Eventual Consistency Pattern

In Micro-services, there is no data that is shared across the micro services. In order to synchronize the data across these isolated storages of these services, we need to apply the eventual consistency pattern. You can read more about applying the pattern correctly here. The simpler way we can achieve consistency across these micro-services is through Event Sourcing pattern.

Event Sourcing

Event sourcing is a process of capturing application state changes in the form of events.  An example of events are customer created, customer updated, Deal created, etc.  Other systems listen to these events and they take relevant action. You can read more about event sourcing here.


Event sourcing is the new way of storing changes to systems and help in making micro-services eventually consistent. These patterns together form well maintainable, reliable and scalable systems in the modern world.