Design concepts.

Prerequisite -  Please read  Controller design pattern  first, t o understand command design pattern better. Background -  This design pattern is applicable for broad applications. I am hoping that you have a good understanding of the  Controller design pattern. Implementing controller would be very difficult without command if you are designing large applications (say 50+ modules).  As we know, the controller is a singleton, and it has to delegate control/work (to one or maybe more than one) modules according to the nature of the request. Writing code to implement this will be very huge (in lines of code), and it will become tough to maintain (that code) in the maintenance phase.  The solution to this problem is the Command design pattern. Let's understand the command design pattern with a classic example - Example -  What operations do we perform in railway web site? Reserve tickets. Cancel tickets. Looking for availability. Track running train status. et

How non-functional requirements makes a difference - First of all  - what is functional requirements? Functional requirement is what your product (or system) is supposed to do. A clear mapping of what the client wants as functionality from your application. Let's understand it through a classic example - Suppose you are purchasing a mobile. What are functional requirements? - OS version? (Should be Lollipop) Camera pixels? (More than 8 MP) Memory? (should be microSD, up to 32 GB) etc...  Now let me ask you one question. Aren't all mobile companies give mobile according to your specifications? But why when you select a mobile for yourself. You get lots of suggestions from your friends and family that purchase Apple, or S amsung, or OnePlus ? Is it because other companies don't build mobiles with that specification? Answer is NO.  All companies have a mobile which belongs to different specifications/segments in general, all XYZ companies offers your funct

Introduction - Let me tell you something that will make you very happy :). Think about a team without having a manager, no one is there to manage you. You are free to work like you want and can behave as you like. Sounds exciting right? Unfortunately this way of working has lots of demerit. Now think about what manager does in high level, if there is any request from outside of the team, it will first go to your manager. He will either reject that request or figure out the nature of request, then resource (or resources) who can complete that work, then assign it accordingly. Apart from this manager has other works as well, but listing down them is not my intention here. Let me think about a team which doesn't have a manager.  As shown in diagram, team X doesn't have any manager and has 7 employees. I am listing out demerits of having this approach - Before, manager was taking care of incoming request, now client has to remember all team member (like kind of wor

Once you understand the requirement, how to propose high level architectural draft is the main question. There are some basic design principles, we can follow and come up with high level draft.  1. Draw the boundary.  You have to have a clear idea about what is in your application's scope and what is not, it is defined by client in the requirements. So draw the boundary and list out all internal and external sub -systems (who will give input to application and how, what all other external sub systems exist).  That boundary will define the scope of the application. Boundary of the system is very important part of scope defining, it gives an idea what is there in designer's hand and what is external. Designer should not worry about anything which is external and not in his control while defining the system and its scope.  There is saying, focus more on what your system is not supposed to do, and don't implement that, make a release note and specify what it is not s