Clean code Tips 2:: Use Top-down Approach While converting complex logic into Methods.

To know How to write clean Method, is the stepping stone of writing proper Clean code, your already know common things like method should be clean, readable, giving proper names, I will not write on this I will focus on the flow of the method, there are two ways to write a complex logic

 a. Top-down approach

 b. Bottom-Up approach, 

for clean code, always choose Top-down approach there are several advantages

 In a crux, your logic should be written as a hierarchy of methods, like an article, let’s say you are reading an article by the headline you can understand what is all about? after reading the first paragraph you will have a crisp understanding of the topic and if you want details then go the other paragraphs.

The same way your methods must be structured. The top-level method must say about the feature, if you go to the next level it will tell about the algorithm, lastly, it will give the implementation details. I like to compose complex logic as a Template method pattern. To know what is Bottom-up and Disadvantages/comparison with Top-down, stay tuned for the next Tip.

Example :: 

  public void displayEvenNumberFromInputSource(){

         

          List<Integer> numberList =  processInputSource();

          List<Integer> evenList = findEven(numberList)

          display(evenList);

     }

Few things to Notice::

displayEvenNumberFromInputSource(), is the top-level method, by reading the name, we can understand it will display even number from an Input source, if I gave the name displayEvenNumber it will not tell the whole story, by reading that one would think it will display even number but from where they get the list of numbers is not there, so the name is important to give accordingly do not think about the method name is too long, actually this is not bad rather Good for your fellow developers, they will thank you later.

Also above method contains the algorithm, the algorithm has three separate concerns and those concerns are abstracted from each other.

processInputSource abstracted the algorithm for fetching the list of numbers, it can be fetched from File, JSON, XML, Command line, but it was abstracted in processInputSource method.

findEven method abstracted the finding even number logic

and display method abstracted the display logic, it can be on Terminal, JSON, XML, Response whatever logic is abstracted in the display.

So, no concern overlaps each other, they have a logical boundary in terms of method, so no leaky abstraction.

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

Reveal the Programing to an Interface Design principles in java.

Programming to an Interface    

I think it will better to discuss design principals in java based on which design patterns are created.

The very first principal is “Programming to an Interface” what does it mean?

Let try to understand the principal in details.

In general, scenario, if you look at any problem statement or business solution you can find two parts.

1.    Fixed part.

2.    Variable

The fixed part is some kind boilerplate code. But when we design we take care of the variable part.

All the design patterns are discovered to maintain this variable parts. Because they are ever-changing. If your code is not flexible with future enhancement, then your code is not up to the mark.

The question is in java How you can maintain your variable parts?

To drill down to answer let magnify the statement "maintain variable parts". we know same will perform an operation but we don’t know How we can achieve this  operation . Specifically, we know the type of the operation but don’t know details of the implementation moreover client needs can be changed so operation implementation  change in future.

Let’s, take an Example A computer monitor is design for display purpose. So I can say if Computer is a product and Computer monitor is a part of computer product.,then Computer monitor is responsible for display operation.

Now, later on, client needs is changed ,now they want to display by Projector

So If our solution is not capable of welcome this needs it will be nothing but a waste product.

According to new needs what we can analyse is, it will perform same action display but the module should change from Computer monitor to Projector.

So display module in Computer product should be flexible so we can change it easily. Or we can change it dynamically(runtime). We can say display module is like a strategy  and client change the strategy now.

So our java solution is like following.

interface displayModule

{

 public void display();

}

public class Monitor implements displayModule

{

public void display()

{

s.o.p(“Display through Monitor”);

}

public class Projector implements displayModule

{

public void display()

{

s.o.p(“Display through projector”);

}

public class Computer

{

 displayModule dm;

public void setDisplayModule(displayModule dm)

{

this.dm=dm;

}

public void display()

{

 dm.display();

}

public static void main(String args[])

{

Computer cm =new Computer();

displayModule dm = new Monitor();

displayModule dm1 = new Projector();

cm. setDisplayModule(dm);

cm. display();

cm. setDisplayModule(dm1);

cm. display();

}                                                                                                    

}

Look the solution, we know Display Module should be flexible, and we know the operation of the display module is "display" but according to the client it may be changed later, but in a computer, there should always be a display module but we don’t know what will that equipment. It’s may be monitor or projector or any other.

So we create an interface and every Display parts should implement that and provide the own definition of the display.

Look the computer class here I create HAS-A relation call display-module because we know display module change frequently as per client needs so we always make display module as abstract

So we can change it runtime with actual implementation.

Remember always code through an interface so you can change your strategy run-time with actual implementation.

The interface means here java interface or abstract class.

Make the variable parts as an interface or abstract class as you know the operation which is never changes but it implementation or the implement module can change.

Read more