Design concepts.

Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one layer. Layer

Background – As we are talking about adaptable system, we have to think about heterogeneous system, we have huge number of different platforms and software stack. If you are thinking to build a system which is portable, you must agree that, you have to design it differently for different platforms. If you do so, you will notice that main (or say core) functionality are same, but you are rebuilding them again and again for different platforms, which is not at all a right way. What I am trying to say is, core functionality will be same, doesn’t matter for which platform and how you build it. So is there any way I can take that core logic as a separate unit? Yes of cures there is, that is what you are reading about, its called “Microkernel”. Please look at below mentioned image for a high level understanding. Microkernal – Core logic/logics of your system, which will be common for all platforms. Internal server - There are some functionalities which are no

I have learnt lazy loading, and implemented it, in my office project, but non-technically speaking, I have learnt it long ago, in my first semester of engineering. One of my best friend Shrikant taught me that. In college days we use to make many unrealistic plans, and after making them we use to vote, who is in and who is out? If someone says no, then we used to curse him, that because of you we are canceling our plan. But Shrikant never use to say no, doesn’t matter how unrealistic you make it. Because somewhere in deep, he was knowing, that plan is not going to work.  At the end when we cancel the plan, he use to pretend that, he was ready but as plan got canceled, so no use of talking about it. You know what, lazy loading works exactly in same way. Out of many functionality (which your application offers), client use only 20% of them all the time. Yes I am talking about 20-80 rule. As past experience tells us that, not all functionalities are in use very activel