How Architectural Patterns and Design Patterns are related to each others

Philippe Krutchen’s 4+1 view model is like the 5 different goggles to view the architecture of any software intensive system. All these 5 different views of software collectively yield the notion of architecture of a software intensive system. Different stake holders of the software are interested in different views of software. But architect has to keep all these views in mind while balancing the different forces upon the software system.

For each view of software, we have various architectural patterns. For each architectural pattern we have different design patterns to structure the fine grained elements in a particular view. So firstly, we have to select the architectural patterns for all different views. For example, we selected to structures our application using the Layered Architectural Pattern. Selecting this, automatically select the Architectural Patterns for other views. Now we have to decide what design patterns we can leverage with in layered architecture to further structure our layers in the form of classes and objects and distributes responsibilities among them.

For example, we selected to structures our application using the SOA Architectural Pattern (extension to layered architectural pattern). Selecting this, automatically select the Architectural Patterns for other views. Now we have to decide what SOA design patterns we can leverage with in SOA architecture to further structure our Service Layer in the form of services and distributes responsibilities among them. As SOA is the extension of layered architectural pattern, so all the design patterns related to layered architectural pattern is still related to the SOA pattern to structure other layers than the Service Layer.

SOA decorates the Service Layer on the top of Business Logic Layer. Generally, Service Layer exposes coarse grained operations than the Business Logic Layer those can be accessed by world-wide software applications (if Service Layer is exposed on the internet) or enterprise-wide software applications ( if Service Layer is exposed on the enterprise-wide WAN or LAN). SOA is SaaS.

OO Design Principles are deeply rooted inside the OO Design Patterns, Amazingly, these Design Principles are few and they are extracted by the in-depth rigorous analysis of all OO Design Patterns.

Are there any SOA Design Principles are deeply rooted inside the SOA Design Patterns, Amazingly, these Design Principles should be few and they are extracted by the in-depth rigorous analysis of all SOA Design Patterns?

GOF Book (Programming in small, Design Issues) à Generally about object oriented software, discusses Design Patterns, discusses programming in small, discusses design issues, applies to all architectural patterns those leverage object-orientation.

Martin Fowler EAA (Programming in small, Design Issues)à About enterprise layered + soa architecture applications, mainly concentrates on Design Pattern. Discusses how the layers should be structures internally by classes and objects. How the responsibilities of a layer should be distributed among the various classes and objects. Different design patterns for this.

Microsoft PnP Book (Programming in large, Architectural Issues) à About enterprise layered + soa architecture applications, mainly concentrates on the issues of Layered Architectural Pattern. Discusses the issues of different layers and CCCs of layered + soa architecture applications. It discusses generally on the very high level about the components with in a layer. It also discusses in short and relates the Design Patterns (classic OO + Martin Fowler EAA) while discussing generally about different components within a layer. It also discusses the other 4 views related to the layered + soa architectural pattern and different design patterns related to those views.

SOA Design Pattern Books (Programming in small, Design Issues) Discusses the issues related to the Service Layer decorated on the top of Business Logic Layer in the context of enterprise layered + soa architecture applications. How to decorate the Service Layer on the top of Enterprise Application and expose the enterprise functionality so that different enterprise applications related to different departments collectively talk each other. There may be network in which multiple Enterprise shared the common WAN and their various applications could talk to each other on co-corporate WAN shared among enterprises. Further things could be put on the Internet and Cloud.

POSA (Programming in small, Design Issues, Programming in large, Architectural Issues) à Siemens Guys Books. Codify the design experience of different systems. Discusses generally about architecture, discusses generally about design, discusses generally about patterns, discusses some design patterns, discusses other architectural patterns and also layered architectural patterns, applications of architectural patterns, server component patterns, about pattern languages, network application patterns, concurrent patterns, focus of the book is quite wide and other type of software applications. 

OO is much more than Linear Sequence Programming

Normally when declare a class type data member in class or when we pass parameters to a method, we assume only one possible use case of this. That is this class need some DATA it is managed like this i.e. by parameter or by declaring it as the data member. We completely ignore the BEHAVIOURAL part of the object. These object are not only the DATA CONTAINERS but they carry BAHAVIOUR as well. For example we can do following things with an object other then DATA

1.       Receiver object can call the methods of passed object.

2.       Receiver object can send method of passed object as parameter it own method or to any other object

3.       Receiver object itself can subscribe one or more events of passed object and attach its event handlers to them.

4.       Receiver object can make other objects to subscribe one or more events of passed and attach their event handlers them.

5.       Receiver object can raise one or more events of passed object and cause functionality to be executed in all its subscribers.

6.       Passed object can  consume receiver’s method as parameter to its own method or it can be passed to any other object’s method as parameter

7.       Passed object can subscribe one or more events of the receiver and attach its events handlers to it.

8.       There can be a complete Zig-Zag between the Passed object and Receiver object. Receiver already has the reference of the Passed object, Passed object know about the Receiver by using the THIS keyword.

9.       There is always a Main program or Startup module that composes the object graph properly and wires the events among the object and inject the dependencies. The resultant object graph is the SOFTWARE that exhibit the required functionality or behavior. This object graph can be expanded by the lazy load technique. The entire object graph should not eager loaded at the startup. It makes the bulky application that takes too many spaces in memory. Also not needed functionality should be eliminated from the object graph.

10.   If an object implements 5 interfaces, then it means that object has 5 different VIEWS or WINDOWS by which its data and functionality can be exposed. Or we can say, object has 5 faces or face-lets by which it can expose its functionality. This is the one use of interface. Implementing the interface means, object can be seen like that. We can hide the show the particular sub set of data and functionality by using a particular Interface.

11.   Provider pattern and Adapter pattern are same, as they adapt the different data sources APIs to be used uniformly for .NET applications. .NET provider for SQL server adapts the SQL server APIs to be used uniformly across the .NET applications. .NET provider for Oracle adapts the Oracle APIs to use uniformly for .NET application. Adapter seems to be a small concept like a class. But in case of provider, this adapter grows to full blown API or Library, therefore these are called Providers. They provide access to the particular data source.

12.   Ideally, the upper layer should depend upon the interface of lower layer, so that the upper layer can be unit tested by mocking the lower layer and provide the dummy functionality. If it is not, then we are forced to provide the PRODUCTION lower layer. If by any means this PRODUCTION lower layer is not available, or it is not possible to provide that, then we can test the upper layers. For example Payment gateways cannot be test in real. Credit card transactions cannot be tested in real. We may not be provided by a SMTP server while testing. Enterprise application has many dependencies on the outer world. While in the test we are not available with those dependencies or it is not feasible to do so. Cause update in the external Database or any other department but we do not have that Database for our application. External service is down or it is under development. Or external service is secures and it could only be used in PRODUCTION scenario. Calling service is not feasible in testing environment. Enterprise service bus cannot be used in Testing Environment and we are not available with Testing ESB.

13.   Repository pattern expose the underlying data source as the in-memory collection and relieves the business logic layer form the underlying details of data source. Along with Unit of work design pattern relieves business logic layer and data from the headache of Transactions, Locking, and Conflicting Updates. All things are managed behind the scenes. Different ORM solutions or Data access Libraries like Linq2Sql, N-Hibernate, ADO.NET Entity Framework, ADO.NET, and Dynamic Data provide the Unit of work mechanism. But using these Unit of work in the business logic make our BLL data source dependent. Do implement the Logical Transactions we need to implement the Unit of Work on the top of Unit of Work provided by the ORM solution.

14.   If the steps and the control flow of the WORKFLOW or ALGORITHM are FIXED and DO NOT CHANGE and the underlying details of the WORKFLOW or ALGORITHM vary and implemented by the developer then this functionality is implemented by Template Method Pattern.

15.   At runtime, behavior can be added to an object, by Strategy Pattern. Composition based solution, delegate behavior to dynamically added objects. We have A, B and C type of behaviors and further we have A1, A2 and A3 type of behaviors. In the same type B1, B2 and B3.

16.   If we have object composition like the stack or like the onion, and functionality is hieratical, then decorator pattern is used. For example, Form composed of may buttons, Data grid compose of many components.

17.   CASE 1: (Client application has upper hand) (We are coding the client application and we want to reuse the existing legacy or incompatible API or Library) Adapter or wrapper is a class that wraps a legacy or incompatible API or Library and exposes that API or Library in an interface that the client code expects. Adapt the API or Library in a way so that it could be used by client. CASE 2: (API or Library application has upper hand) (We are coding the API or Library and we want it to be reused by all future expected clients) Adapter or wrapper interface is exposed by the API or Library; all interested clients implement that interface exposed in order to use that API or Library.