Layered Architecture Up and Running just in 5 minutes:: Spring Boot Part 1

This is a two-part series where I will show how to create a Layered architecture with Spring Boot. 

What is a Layered Architecture: In a simple term when we building an enterprise application, we maintain different layers to encapsulate layers specific logic so that, it can't be spill over to another layer. When we think about an enterprise application we can imagine three important layers of the architecture. 

1. User Interface: Which interact with the end user, shows data to them, take user input, take command from them etc.

2. Business Layer: Based on the User command and the data captured from the user(AKA Form), It takes a domain-specific decision, like what to do with the data, which table to look, how to manipulate the data which comes from the database, so it can be presented in UI.

3. Persistence layer: This layer captures the data and persists it, same also capture any updation, deletion, and change of the state of the data, so you can consider this layer as, maintaining a state of the Application Specific Data.

Irrespective of your application is up or down it stores the state of the data once committed.

By layered architecture, we create a logical encapsulation of each layer like all the code, respect to UI stays in the UI layer, all code regarding business logic stays in Business Layer etc.

Each layer communicates with its adjacent layer, but never communicate with another layer which is not adjacent.

So if you have an application which has three layers UI, Business, DAO, UI communicate with Business, Business communicate with UI and DAO and DAO communicate with Business. By this way, we can reduce coupling, makes layers reusable and welcoming the future change in the architecture. Each layer has it's own pattern to accommodate future change an make the layer reusable.

We all know Spring provide different components for each layer like, for UI you can use Thymleaf or Spring template or any other UI framework like JSF, for Business layer,  you can use Controller and service, Also you can inject different framework like Struts in to it, For Persistence layer you can use Spring data JPA, Hibernate, JDBC template whatever. But the problem is you need to add all the plugins/Jars in your pom.xml find the right version of the dependencies in the classpath, If version mismatches it will not going to work also you need to add many Spring specific annotations or XML entries in Spring XML files to use those component/plugins in your layered architecture, which is a cumbersome method also you need to package them and deploy them in an application server, so many manual interventions needed. Spring addresses this problem and comes out with a solution which they Called Spring Boot.

"Spring-boot works by convention over configuration" --  It means you don't have to think about configuration entry, only pay attention to your business logic, whatever the component you want to use if those are mentioned in your classpath Spring boot is so smart that it will understand you want to use the same and configure a fully working components for you. Say you want to use JPA in your project, if you import Spring boot starter JPA module, it understand you want to use it and on the fly it creates the Spring template a repository and utility CRUD methods for you, without Spring-boot you need to configure the JPA template, Initiate a session factory from template, get the session etc., those are just not required here, Spring boot is so powerful that it can do it for you, and of course If you want to control the configuration by yourself you can override them and use your own configuration.

In this tutorial, I will show you How to create an MVC Layered architecture Step by Step using Spring-boot, and you will be amazed within five minutes you can create an MVC architecture Up and running, which previously take lots of time, and lots of head scratching in case of version mismatch.

As it is a two-part series, In the first part we will setup a database, insert Employee data into the database using JPA repository.

For this tutorial, we will use the following components

1. H2 Database: Which is an in-memory database, It persists the data until the application closed. 

2. Spring Data JPA: we will use Spring data JPA component for CRUD operation in Database.

3. Rest Controller: Which will show the data in a JSON format rather than forwarding response into a View, unlike traditional MVC.

Step 1: Go to start.spring.io and download a template project by selecting Web, JPA, H2 Module.

Step  2: Import that project into eclipse as maven project.

Step 3: Check the pom.xml, spring-starter-web,spring-starter-data-jpa,h2 module entry will be there. These are Spring boot packages which contain all the necessary dependencies for jpa and web and maintaining right version of dependent jars so that there will be no version mismatch problem.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>com.example</groupId>
<artifactId>layerdArchitechture</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>

<name>layerdArchitechture</name>
<description>Demo project for Spring Boot</description>

<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.4.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
</properties>

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>


</project>

Step 4: Go to application.properties file under src/main/resources and make the h2 console enabled true so we can see the data inserted in the h2 database.

spring.h2.console.enabled=true

Step 5 : Let's create an Employee entity.

package com.example.layerdArchitechture.entity;

import javax.persistence.Entity;

import javax.persistence.GeneratedValue;

import javax.persistence.Id;

@Entity

public class Employee {

@Id

    @GeneratedValue

private Long id;

private String name;

private String address;

private String sex;

public Long getId() {

return id;

}

public void setId(Long id) {

this.id = id;

}

public String getName() {

return name;

}

public void setName(String name) {

this.name = name;

}

public String getAddress() {

return address;

}

public void setAddress(String address) {

this.address = address;

}

public String getSex() {

return sex;

}

public void setSex(String sex) {

this.sex = sex;

}

@Override

public String toString() {

return "Employee [id=" + id + ", name=" + name + ", address=" + address + ", sex=" + sex + "]";

}

}

Step 6: Now create an EmployeeRepositiry interface which will extend the CrudRepository interface, Spring-boot on the fly creates an implementation and create all the utility(crud) methods we don't have to do anything but just declare the interface.

package com.example.layerdArchitechture.repository;

import org.springframework.data.repository.CrudRepository;

import org.springframework.stereotype.Repository;

import com.example.layerdArchitechture.entity.Employee;

@Repository

public interface EmployeeRepositiry extends CrudRepository<Employee, Long> {

}

Step 7. Now create a Data Loader class which will insert few employees into the H2 database using the above-created repository. For that, I have to auto-wire the EmployeeRepository interface. Please pay attention to loadData method here I create a list of the employee then iterate of the list and save those data in H2 database by using of lambda expression in Java8.

package com.example.layerdArchitechture;

import java.util.ArrayList;

import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Component;

import com.example.layerdArchitechture.entity.Employee;

import com.example.layerdArchitechture.repository.EmployeeRepositiry;

@Component

public class InitDataLoader {

@Autowired

private EmployeeRepositiry rep;

public void loadData() {

createData().forEach(

emp->{

rep.save(emp);

System.out.println("Successfully saved ::" + emp);

}

);

}

private List<Employee> createData() {

List<Employee> employees = new ArrayList<Employee>();

Employee emp = new Employee();

emp.setName("Shamik Mitra");

emp.setSex("M");

emp.setAddress("BagBazar");

Employee emp1 = new Employee();

emp1.setName("Samir Mitra");

emp1.setSex("M");

emp1.setAddress("BagBazar");

Employee emp2 = new Employee();

emp2.setName("Swastika Basu");

emp2.setSex("F");

emp2.setAddress("Baranagar");

employees.add(emp);

employees.add(emp1);

employees.add(emp2);

return employees;

}

}

Step9 : We need to tell our application to scan all Spring beans and find the JPA repository and entity files and register them as Spring bean, so we will use two special annotations 

@SpringBoot and @EnableJpaRepositories, on top of the Spring boot main class. Please note that in @EnableJpaRepositories annotation,  I mentioned the root package from where it start finding the repository and entities

package com.example.layerdArchitechture;

import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.CommandLineRunner;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.ComponentScan;import org.springframework.data.jpa.repository.config.EnableJpaRepositories;

@SpringBootApplication

@EnableJpaRepositories("com.example.layerdArchitechture")

public class LayerdArchitechtureApplication {

public static void main(String[] args) {

SpringApplication.run(LayerdArchitechtureApplication.class, args);

}

@Bean

public CommandLineRunner loadData(InitDataLoader loader) {

return args->loader.loadData();

}

}

Pay attention to the loadData method, this is Java style bean configuration where I call InitLoader's load data method. CommandLiner bean will be invoked when the application starts and inject InitDataLoader as a Spring bean(IOC), So I can expect upon starting my Spring boot application I will insert all the data into the database.

Step10 : Start the application and we can see employees are inserted in the database to verify that go to the following url http://localhost:8080/h2-console we can see the following 

Conclusion: we have successfully insert data using Spring boot, one thing to observe here, To insert data into the database we don't have to write a single line of CRUD code and JPA template configuration code. Spring boot does the same behalf of us. In the second part, I will show you how to expose hose data as a JSON format so any UI framework(Angular5) consume data as JSON or use this layered architecture as a Microservice(Few Changes needs to make it Microservice component), Stay tuned.

Read more

Dilemma on Utility module , making a jar or separate Microservice?

In my previous article, I talked about How you can come to a conclusion about what to choose for your new project Microservice or Monolith? 

As an architect may you follow the points what I mentioned in the previous article and come to a conclusion that you will be going to use Microservice Architecture, A big cheers for you, You promoted yourselves as a first-class citizens of the new era of  Digital world, but(when but is used it means the previous word is meaningless/no value until you solve the next part of but :)) what's next , you heard about Microservice Architecture demands Componentization of service but what is actually a component in Microservice world?

In this article, I briefly discuss What does it mean by Componentization, and when we need to do Componentization of a Utility module what problems we faced?

Componentization of service:: By the word "Microservice", we can understand it is a suite of small services, so the main objective is breaking a project into multiple services. But what does it mean by services, Which kind of services are those? Are we talking about a Service layer in a layered architecture, or a service wrap into the jar so-called "Library" or publish it through REST API, what is that?

To understand always remember "Microservices means an Independent thing(Component/Service whatever you call it) that can be deployed independently and update independently manage it lifecycle independently".

When you Create a Microservice very clear about that, There should not be any confusion, Maybe many tricky situations come but stick to basics "Microservice mean an independent deployable thing".

One of the best dilemmas is,  Suppose you have a utility module, now you are in a confusion what should you do,  wrap utility module into a jar and all other Miocroservice use the same as a jar , so that there should not be a code duplication or expose a utility service with API fiction(Separate Microservice)  so others can consume it.

One may think, making utility module as a jar   seems severely wrong in Microservice workspace as Microservice means several independent small services so Utility module  should be published as a service,  so Utility module must be a Microservice,

Why is the Utility module as a Jar a bad Idea?

when you import utility module as a jar you limit yourself, Now Your service is dependent on utility module which packaged as jar, If utility modules  java version upgrade you have to upgrade your service unless your program not able to use that jar, Now you both should stick in same language java(Although once service is written in one language, I saw rarely that is rewritten in another language), having said that,  you should not confined  your Microservice to a language(Java), Think your utility module is used by many microservices as a jar, so if you want to upgrade your version  it should be backward compatible, say you want to create functions which can easily be achieved by java9 but you can not upgrade your utility as other microservices not upgraded to java9.

Why Utility module as a Jar is a good Idea?

As a counter logic many can argue, To build a Microservice itself, we  import jars/Libraries like Sprint boot starter parent, or GSON, Jackson etc, so why we should not package our utility as jar why it is a bad idea , Even let me tell you, many architect think it is a brilliant idea as  it solves many purposes.

If we are not using utility module as a jar then we have two options

1. Duplicate the functionality of a utility module in all Microservices.

2. Create a Microservice called Utility service and publish an API to invoke utility methods.

These two options has there it's own demerits.

1.  Duplicate the functionality of utility module in all Microservices::Here the objective is duplicate the code to all Microservices who consumes Utility module, so that there is no utility module as such, all are the part of local codebase, but it is against the DRY principle and bad idea, If the utility module is holding some complex code which associates many classes, unnecessary that has been copied to all Microservices and any future changes in that, has to be copied over all Microservices. So there is a problem of maintainability, say we have a utility module which calls an External service and get a complex response then this module parsing the responses apply some business logic on it and create some analytical data which exposes as public methods (Java API), Now if you copied that complex algorithm written in Utility module in to multiple services certainly it is a very bad idea, think how many time duplication has been done, and if now a new analytical data is needed you have to add it in all Microservices , oops what a pain while I am writing this I am getting feared to imagine the scenario. So certainly it does not work unless you have a very small portion of utility code and which is not changeable say a generic code which deals with Date, TimeZone, and Format, ( A single class with multiple static methods), Copying that class in all Microservice is a onetime effort.

2. Create a Microservice called utility service and publish an API to invoke utility methods : 

So, you create one Microservice where all utility methods are dumped, as this is a Utility module all Microservice or most of the Microservice Communicate with it, So Every Microservice has a link with this Microservice, So just imagine the picture every Microservice dependent(HAS-A) on it , So If that service is down due to some erroneous code or all instances down due to some major causes, All service will be down Total Microservice architecture is doomed then How it is different than a monolith?

As per Microservice, Partial failure may happen but total Microservice will not down ever, It has 100% uptime.

So certainly creating a Utility Microservice not looking very promising.

As an Architect What should you do now It is like a double-edged sword, whatever the option you choose, You have to deal with demerits.

Taking a decision :: As an architect, we always dealt with Demerits and try to choose in which case, which one to choose so it has least demerits, So, As an architect our favourite answer is "It depends on scenario", and we are hated for that answer, even Juniors are mocking us he does not have direct answer always said it depends.

Here I also giving answer in a same way, It depends :) How your utility method is written, in a one liner if your utilty functions are statless use Jar , If your utility functions are dealing with State use Microservice.

If you observe minutely, you can divide your utility methods into two categories.

One type of utility modules takes and input doing some operation on it and returns a result so there are no side effects and it is independent of any parameter state, every time you pass the same parameter you got the same result, In this case do not publish those as separate Microservice, as this is not dealing with state , so no need to publish as REST resource, because no create, Put ,delete operation done by this, So, you can package this as a jar and use in every microservices, Think about Utility jars like Jackson,Gson thy take request do some operation returns some data structure, But if your utility takes and request fetch some data from database, do some operation and return it or save that state in database, then it would be ideal to publish it as Microservice.

Here also think about the failure, if you make a synchronous operation then your utility module fail means all chain of Microservices is failed, so think can you make utility operation as async, is the utility module require in sync fashion? As an example Event store or store Audit information, Those are cross-cutting concerns and a utility operation so it is not a part of main business flow so we can make that async so that if audit information or even storing operation fails it does not block the business flow and your service should not down for it.

If you have to use utility operation in sync fashion, then implement a circuit breaker and return a default path, so that if the operation fails it does not block all Microservices, at least if show a default path and show the user a message. or users can perform other operations rather that this function (Say your transaction function calling a utility function to check Transaction amount and based on that bank giving you some credit points, now if that function fails we can show a default message "at this time we can't process transaction" but user can do other options like balance check. So any moment of time the service will not totally down.

Conclusion:: There are also different shades of Utility some are mostly read-only but has database operation, some may use in-memory caching so take decision wisely How you want to write your utility one,  jars or Microservice.

Read more

Microservice Vs Monolith:Which one to Choose?

"Microservice" is a Buzzword in the industry right? Apart from Microservice design rest of the design marked as "Monolith". But as an architect when you trying to create a new Software based on a specific Domain, What will you do , adopt Microservice without judging anything as this is the hit one,  every one runs behind it or just stop for a second and think about your company infrastructure, employee expertise and based on that choose Microservice.

As an Architect it is our duty to choose Microservice when it is required, Not going with the flow and use Microservice. This tutorial I will talk about few aspects, which I think most important before you adopt Microservice, and I am open to hearing any other proposal or aspects to cover which I missed, Even counter logic, This is my realization while working In Microservice and so-called Monolith, both the architectures.

Let's begin with the aspects to consider before choosing Microservice as default architecture.

1. Project associates Strength: While you are getting a project first parameter to consider is to How many associates are going to work in this project and what are their experiences. If your strength is low, like 10-12 don't go for Microservices , as Microiservices means independent services , and the motto is "You Build it you run it" so There should be one team have complete ownership on a Microservice, If you associate strength is small statistically each one or two persons will have ownership of two or three Microservices, and it creates a critical problem, Knowledge is confined to them and they will become a Pivot employee, On Another side If one/two persons take ownership of two or three microservices, the motto, Developers should only focus about a small portion but know everything about that service is going to break. So think about that.

2. Microservice and It's associate Knowledge: Microservice is a new architecture and there are various concepts inter-related with Microservice like Distributed Artechtures rules, like High availability, Resiliency, Service discovery, CAP theorem, , Domain-driven Design, Circuit Breaker pattern, Distributed cache mechanism, Route Tracing etc. Not only that DevOps culture is tightly coupled with Microservice in order to unleash the full power of Microservice, So you need to know CI/CD tools and it's culture(Automated deployment).The team should be efficient to drive all of these for a Microservice, If the Microservices deployed in cloud or container, Team should have an understanding of Cloud architecture(PCF, Amazon, Bluemix etc) or Container architecture.(Docker, Docker Swarm, Messos, Kubernetes etc). Think carefully about the Team knowledge, always think when you are dealing with Microservices it means multiple services and multiple teams, so each team member should have clear understanding all of the associated knowledge to run it's Microservices independently, If you don't have such leisure make sure for each team one or two persons, who know all the associated knowledge so they can educate their team. 

Organization Infrastructure: Another important dimension is Organization infrastructure, Before adapting Microservice always check in what mode you organizations work, As per Conway's law whatever your organization structure that is reflected in your code implementation, So check,  is your organization adopt the Agile technology? Is the team  built with cross-technology member (Like UI, Middle layer, Database), What are the deployment and QA test mode, is your organization follows manual deployment and manual testing, or they are already or going to adopt DevOps culture, Where the artifacts going to deploy, is Organization has few servers where you install Application servers and deploy your artifacts or Organization move to Cloud. Based on these parameter choose are you going to adopt Microservices or not , If Organization has its own servers(few) where application servers are installed, in that case, all the different Microservice artifacts going to deploy same server space, which does not fulfill the Horizontal scaling so Microservices adoption will be in danger, also in case of Manual testing and Manual deployment if you adopt Microservice it is a nightmare for Ops team and QA team, also for developer it is nightmare to integrate the changes and test in SIT. 

Domain Criticality: Check the nature of the domain you are working on, sit with Business analysist understand how critical is this, is there such a need where we need to break domain into subdomains, so that related function can be encapsulated under a context, based on that take decision if Domain is not very complex , It is better to stick with Monolith, no need to create Context map and encapsulate subdomains in a Bounded Context.

The budget of the Project: This is another important aspect to look on. Think about the budget of the project, the nature of the project is it fixed bid or TNM type. Microservice projects are expensive than monoliths as it needs more server or cloud infrastructure, Automated pipeline, Count of Resources, all team should be cross skills team, So in terms of  infrastructure and resources level it is much more costly than Monolith, so think about what the budget aligned with your project(Secretly I am giving one tip to you, Please do not publish to anyone, As a good Loyal Architect Always Think about Revenue margin, a modular monolith is better than Microservice in case of small budget it serves the purpose of  Revenue and In future if you want to move Microservice also that is possible.)

Conclusion : Nowadays, Microservices technology hit in such a way, Novice or mid-level developers think Monolith means bad it is a BBOM(Big ball of mud) all modules are strangled with each other, but If you maintain modular approach, It is good and many cases it is better than microservices when our resources are finite. So choose carefully not go with the flow. I always recommend to go with Monolith first but makes it Modular, If you use Java9 use Module else you can adopt SOA but start with modular one and when there's an actual need, like Module boundaries are going to leak, or you can't maintain Acyclic Graph (DAG) among modules, Then think for beaking Monolith basis on DDD and can lean towards Microservices. Not before that, what I am trying to say is Do not use Microservices as Others are adopting it, Adopt it when you need it. Many cases I saw some project try to adopt Microservice but just because of lack of knowledge they create such a project  which is neither a Microservice and nor a Monolith, They create many services, without a proper encapsulation and each service chained with other in such a way one Agile team can't take an independent decision on deploying one Microservice, multiple teams ,  multiple artifacts depends on each other , Teams are blaming each other as functionality span over many services , It is a horrible situation, I will discuss that  in my future articles, But for now think twice before adopt Microservice as Uncle Ben said  "Great power comes with Great Responsibility".

Read more

DDD::Interchange Context and Microservices

In my previous two articles, I describe lots about Bounded context and context map, where we have learned, How to segregate the domain models using Bounded context?  Also learned, How to use context map judiciously to understand the relationship between two contexts, here relationship is a broader statement it does not only represent technical relationship it also defines the relationship between owners of the services, who is in commendable position, who act as downstream etc. Also, we learned different strategy based on the relationships like (Partnership, upstream/downstream,anti-corruption layer etc).

In this article, we will be dealing with a special case when something goes wrong while designing a Microservice. Then how that error bleeds and corrupted other services, Then we will learn how to solve that problem using Interchange context.

Take an Example, In case of our online Student registration module where Registration Module is in commendable position, as it has a partnership relationship with analytics module, Payment module has a downstream relationship with it, Batch scheduler has a downstream relationship with the same.   so it is clear Registration module is in commendable position, so the language it published every one has to follow that language, by Registration module API whatever the message it publishes batch, and payment module has to receive the same message , so I can say if the Registration module publish an R language every other module has to consume that R language, So  in this system R is the defacto language standard. You can think of this situation on the real-world basis as British people conquered the world in ancient time, so the language they speak i.e English is the defacto language standard for world, A British man and an Indian automatically communicate with English not the reverse even an Indian and a Chinese also talk to each other by English (where no British people are involved).

Now, The problem occurs If the Registration Module has some issues in Design, say Boundary is not properly defined, Message structure not properly designed or Edge cases or Exceptions are not handled properly in that case in spite of a Physical boundary(Bounded context) this problems are bleed into all dependent services, as whole context map is polluted due the error in Registration module. So Registration Module now acting as a Big ball of mud. (BBoM). As per Eric Evans, he called it a Small ball of Mud. So one thing is clear if upstream/commandable system is in danger then the whole Microservice architecture become a mess. As an Architect somehow we have to prevent the bleeding of errors from upstream Microservices/ System to downstream.

If we dig through the DDD patterns we can found ACL is doing the same (Anti-corruption layer) which sits in front of consumer Microservice/System and translate the producer /upstream message structure to Consumer Microservice/System message structure also it handles any kind of errors , So ACL protecting the consumer services from External systems.  But think about a system where two services are in a Partnership relationship

they produce and consumes each other messages both dependent on each other and other services dependent on them, in that case rather than putting ACL in front of both Partners we can use a new concept called Interchange Context.

Interchange Context, is such a technique where both partners agreeing upon the model and message structure, so there is one ubiquitous language for both partners, they publish one Message together and other systems consume that message. In this way, two partners can independently change there internal code, internal message structure but in Interchange context, they create a common terminology/Ubiquitous language which understood by this two partners. Every other service, who are dependent on these two partners can consume message from Interchange context.

Conclusion : Interchange context is more robust that Anti-corruption layer, it stops the error to be bled from upstream services , If upstream services has a direct consumers then , upstream service developer should be very careful about the API , any changes in API or errors break others , so Interchange context is kind of centralized facade where partners are created the ubiquitous language and other costumes message from interchange context, partners and dependents services all are free to modify there own data model, message structure but when they communicate to interchange context internal model should converted to Interchange context message structures.

Read more

DDD: Thinking in terms of Context Map

In my previous article, I did a detailed discussion about the Bounded Context and learn that how to tackle the complexity of a Domain, it is the best way to divide the domains into several subdomains and mapped them with different bounded contexts where each business entity/Value object has certain meaning on that context, so every stakeholder of the business like Product owner, Developers, Architect, sponsorers are understood the context and referring entity with the proper name, there should be no confusion of the naming when we discuss the terminology basis on a context. A ubiquitous language which creates a unified language among business stakeholder.

By Bounded context, we properly define a business model, create a different context based on the business domains, but always a functionality spans over multiple business entities , and those entities lie in the different Bounded contexts/domains, so it is utmost important to understand the relationship between the Bounded contexts, to architecting the business solution Context Map is a technique by which we can visualize the relationship between different contexts and Integration architect choose the best integration patterns to communicate to other contexts.

Why Context Map is so important while designing solution?

By UML diagram architect cam understand how different parts will communicate with other parts, It gives the architect a view on the communication between different contexts, that is fine but context map stepped in before UML diagram, it helps to visualize the nature of the relationship and based on the nature , architects can decide what kind of technical solution would be adopted.

The best part of Context Map visualization is, it talks about nature of the relationship, It not only tell is that relationship is upstream or downstream, Publisher or subscriber, it also tells how different team dependent on another team their motifs, their politics everything. so counting all of that now architect in a position to decide optimal solution to minimize the risk while integrating with another context.

In the era of Microservices, Context Map is the key player, because before design the holistic Microservice architecture where every team owns a Microservice, It is important to understand how one team is dependent on other, which teams are in commendable position, which team only seeks help then you can architect the solution best possible way .

Think of our Student online Tutor app, as a full grown app say it has more than fifty microservices are deployed in production , so here fifty teams are coming into play and for developing a functionality say Student registrations , multiple contexts will be affected, so we can say to implement that feature multiple teams will be involved so what would be their relationship, while designing this feature who is the pivot service whose data is most needed obviously that service is in commendable position as if that team is not ready other teams can't do anything, so all teams should align with that team , they have to sync there product backlog with that team, so here the internal politics comes to the picture , if the data of the service comes from an External team not with in the organization then the solution is way more complex as you can't force them so only way is to request them and wait for there changes, so based on these diffrent scenarios, politics context map has diffrent solutions. I will cover most important solutions here

 1. Shared Kernel : Shared kernel talks about a partnership relation where two or many teams shared common data model/ value object, it reduces the code duplication as different context use that common model, but that common model/value object is very sensitive, any changes major/minor should be agreed upon all the parties unless it would break other parties code, so more communication and synchronization needs among those teams say one team need a change in the common model but another team is not ready so the priro team has to wait for other oartner to be ready or otherhand othar partner has to change there code unnecessery although that is not heliping them, but to be in sync with other partners, diffrent shades of problems woven while maintaining the pertnership relation ship so choose that pattern  when your common model remains constant or changes once in an era.

In our example, say we developed an analytical module which analysis which courses are most chosen by the students, which students are chosen more than five courses etc, so that module works with Student model, course model so I can say our Analytics module can share Registration modules student model, and they also agreed upon any changes on student model.

Customer/ Supplier: Generally this is the common relationship between two contexts, where a context consumers or depend on data from another context, the context which produces data marked as upstream and the context which consumes data called downstream. When we visualize this relationship in terms of politics we can visualize the power distribution has many shades.

like following

Upstream as the leader: In this type of relationship, the upstream team is in a commendable position, that team does not care about the downstream team, as they producing the data and downstream team is on the mercy of that upstream team they are always changing their model based on the data structure produces by upstream.

In our Student Registration app relationship between Payment app and Notification, app is kind of upstream and downstream where Payment app decide what information in which structure they provide and Notification module consumes that data structure.

Downstream as the Leader: In some cases, the relationship is revert although upstream is produces data, it must have to follow the rule, the data structure for downstream, in this scenario downstream is in a commendable position.

say in our Studen registration system we need to submit Form 16 to government as a tax payee so our payment module has to submit form 16 data to Government exposed API but government API has certain rules and data structure for submitting form 16 data, so although government API is downstream it has total control, our Payment module should communicate with down steam in such a way so it can fulfil downstream rules.

The customer-supplier relation works best when both the parties upstream and downstream are aligned with the work both party agreed upon the interfaces and change in the structure, in case of any changes in the contract both parties will do a discussion synchronize their priority backlogs and agreed upon the changes, If one party does nor care upon another party then every time contract will be broken and it is tough to maintain a customer-supplier relationship.

Conformist: Sometimes, there is a relation between two parties in such a way that downstream team always dependent on an upstream team and they can't do a mutual agreement with upstream about requirements.  The upstream is not aligned with downstream and does not care they are free to change there published endpoint or contract any time and not taking any request from downstream. It is happens when Upstream team is an external system or under a different management hierarchy , and many downstream systems are registered with it so it can't give a priority to any downstream, rather then all downstream system must be aligned with upstream contact and data structures if upstream contracts or data structures change it ps downstream responsibility to changes accordingly.

Say, In our online Student registration app we have a free tutorial module where all students or other application can consume our free tutorials and embed them in their application, so here out free tutorial module acts as upstream and independent of any other third party app who consumes our free tutorials , we can;t give any priority to them and we don't have any contract with them if we change the contracts or data structures it is other third parties duty to change their application accordingly to consume our free tutorials. Other parties are acting as a conformist.

Anti Corruption Layer: When two system interacts if we consume the data directly from upstream we pollute our downstream system as upstream data structure leak through the downstream so if the upstream become polluted our downstream too as it imitates the upstream data while consuming. So it is a good idea while consume data from third party or from a legacy application always use a translation layer where the upstream data translate to downstream data structure before fed in to downstream in that way we can resist the data leakage from upstream, if upstream contract changes it does not pollute downstream internal system only Translation layer has to be changed in order to  adopt new data structure from upstream and convert it into downstream data structure, this technique is called Anti-corruption layer. Anti-corruption layers save the downstream system from upstream changes.

In our application Notification module can implement an ACL while consuming data from payment module so if payment module data structure changes only ACL layers affected.

Open Host : In some cases, your Domain API needs to be accessed by many other services like our Free Tutorial Publisher module, Many external or internal domains want to consume this service, so as Upstream it should be hosted as a service and maintains a protocol and service contract like REST and JSON structure so another system can consume the data.

Published Language: Often two or more system receive and send messages among themselves, in that case, a common language will be needed for the transformation of the data from one system to another like XML, JSON we call that structure as Published language.

The holistic  view of our Student online registration app in terms of context Map

 Conclusion: Context Map is a very important exercise to realize how one domain communicate with other, It gives a proper view of the organization structure, how different domains are distributed, how domain owners are dependent on each other? What is the relationship between team structure? Can they be aligned while developing a feature, based on all the parameters Integration architect can adopt a suitable integration pattern to integrate domains? Prior to designing the integration solution, always architect has to define context map to understand the relationship and structure of the teams based on that Architect can choose the best possible solution.

Read more

Bounded Context in my view

In this article, I will share my view about Bounded Context,
What does it mean,?
Why is it required?
The connection between Bounded context and Microservices.
I will try to keep it simple, and this article targeted to that audience who will hear the term Bounded Context while developing Microservices but having a hard time to understanding the Bounded context concept.
Before deep dive into Bounded Context in terms of DDD(Domain Driven Design), Let's understand what is the meaning of that in the real world.
We know the human is the most intelligent species and created different countries for the ruling. But Question is Why they created different countries or Logical Boundaries? In what basis Boundary has been drawn between two countries,  before Human civilization, in the Earth, we only have land there is no concept of country.
One compelling answers come to my mind is that to separate the administration, culture, laws, economics, so each country abstracted its people from other countries unless it is an impossible task to create one Unified culture, language as in ancients time different tribes has there own languages and cultures.
In the same country, there are some predefined rules, language, style every citizen follows. They understand the common language, aware of laws, currency, style so as a brief I can say, Citizens are sync with each other in a country and country has one Unified culture which every citizen follows and understand.
In programming, We apply Bounded context in the same manner, to separate different models/subdomains  from each other in a Domain/Problem space, In a Domain-driven design --Strategic design part,  we introduce Bounded context so in a certain context a model has a certain meaning like the countries where for a particular country--ceratin language, currency has specific meaning, But in a different country that currency or language is not understandable, Because it has no meaning/different meaning respect to that country. Like the word Fool, In English it means Stupid but in Bengali it means Flower !!!!
So If we consider Country as a Bounded context, and language/currencies as a Model inside that context we can easily map the concept of the domain model in a certain bounded context. The model has some meaning for a Bounded context but the same model has no meaning/different meaning for another Bounded context, So by Bounded context, we create a logical boundary where the model and business terms have a certain meaning and the Bounded context separate/hide the models from the outer world. All communication should be done via API. So it is obvious that under a Bounded context -- model and business logic maintains a certain law and maintain its own persistence storage and that is not directly accessible to other Bounded Context.

BoundedContext Communication: Any design has two common parts, abstraction of the data model and communicates with other parts of the system. By Bounded context we separate the data model in a simple term abstracting the commonalities in the business but How one Bounded context communicate with others?
Here the concept of Context Map stepped in, Using Context map we can discover How one Context depends on other Bounded Context, Like are two Context has strong dependencies. or one domain sends a confirmation message to another domain(Conformist) or may use a shared kernel/Shared model, I will talk about Context map later in a separate article, But as of now, you can think context map is for communicating clearly between Bounded Contexts.
At this point, I believe you have a fair bit of idea what is a Bounded context, But still, if you have questions How it fits in Architecture? go to the next paragraph.
Let say we have to design Online Student management system where Student can register to the site choose course accordingly, Pay the Course fee and then he will be tagged to a batch and Teacher & Student is notified about the batch start date and time slot.
As an Architect, you have to identify the bounded context of the different domain related to this business logic.
If we divide the business logic based on related functionality we can found four basic functionality
1. Registration process: Which takes care of Registration of Student.
2. Payment System: Which will process the Course fee and publish online payment status.
3. Batch Scheduling: Upon confirmation of payment,  this function checks the Teacher availability, batch availability and based on that create a batch and assign the candidates or update an existing batch with the candidate.
4. Notification System: It will notify Teacher and Student about the timings and slot information.

So, There are  4 bounded contexts Registration, Payments, Scheduler, and Notification.
Now let's dig down How each Module represents Teacher and Student and Course Models.
Registration process: It only wants the Student information and it needs it demographic information like Name, age, sex, address and which course student chooses.
There is no mean of Teacher in this context
Payment System : It treats Student as Candidates In Payment System only Student/Candidates financial information is required like Account number and based on the course fees it deduct the amount from given account, So here perspective of a student is totally different, Information needed in payment Service is totally different from Registration although Payment system may need few pieces of information like name, address of the student those are very minimal information.
The term "Teacher"  is not valid here, In payment System Teacher treated as Faculty and they can be permanent or Contractor based on the Faculty type Payment System choose the payment calculation either per hour basis or per anum basis.
Batch Scheduling: In case of Batch Scheduling System, it needs bare minimum information from Teacher and Student like name, Address etc. But it needs detailed information, of Course, Batches under the Courses etc.
Notification System: For Notification System, we just need the Teacher and Student email address or Phone number and name nothing else, And it needs the name of the Student management system and Course details, here Student management site acts as Sender and Teacher and Student denotes as Reciever.

Till now we have seen,  same Domain Objects Teacher, Student, Course have different meaning and use-cases for different Context, This is the beauty of Bounded Context ,we have multiple canonical models for same domain Object based on different context, So developers, Business, user are always in the same page when they are talking about a context, the concept of ubiquitous language is woven here, using ubiquitous language DDD create a unified system where every participant understand the language based on the context.
Now, the common question is why the Bounded context term is so popular in Microservices?
To answer this questions first we have to understand that DDD is applicable for Monolith as well as in Microservice, But in case of Monolith, it is vaguer and more of a logical segregation so only good developers can see it. The main reason is in monolith we have a single giant codebase, may we break it multimodule based on DDD create ACL/Translator when one module talks to another but still it needs other modules as dependent jars to invoke its method. Another point is as this is a single code base and multiple coders working on them so some not so skillfull coder can pollute the boundary or domain Object, Architecht can't create a physical boundary based on Bounded Context, But in Microservice architechture it is inherent as Microservice said that rather than a large code base we can create Small services which have it own code base and services are talk to each other through API or messaging, so It clearly says that understand the Business Domain break the Business logic in to multiple Bounded Contexts and each Bounded Context will be a separte codebase and they comuunicate through Context Map, To design the Context map you have to design API carefully, may you can use Port and Hub architechture So your code under the Bounded context is not comminicate with Outerworld and never polluted. Microservice offers this type of strong segregation of Bounded Context. Bounded Context is more visible and understandable in the context of Microservice.
Conclusion: Bounded Context is the basic needs, when you are trying to break a large business logic it helps you to understand how different part of the system use domain objects in a different manner with different terminology. Bounded Context is just a view to properly organize the business logic based on functionality but to make the business logic works --  communication between Bounded context needed, and it uses Context Map for the same. In my next article, I will discuss Context Map.

Read more