List of Handy Architecture & Design Patterns for Developers & Architects

[adsenseyu2]
If you are a newbie developer. experienced developer, aspiring to be architect or an architect, you may want to keep following architecture & design patterns handy with you to solve day-to-day software architecture and design problems at your work place. These patterns can be applied for developers/architects of varied experience level, having expertise with various different technologies (programming languages). Please feel free to suggest additional patterns as if I may have missed some of them.
  • Application Architecture Patterns: These patterns primarily are related with topics such as how to layer an enterprise application, how to organize domain logic, how to tie that logic to a relational database, how to design a web based presentation. Some of these patterns can be found on following martin fowler’s page that lists patterns from his book “Patterns of Enterprise Application Architecture”. Patterns fall in the high level topic areas such as web presentation, object-relational structural, behavioral, metadata mapping etc. These patterns can prove very useful for software professionals who have spent some time in IT and want to move to next level by taking part in laying down architecture of various systems.
  • GOF Patterns: These are twenty-three design patterns described by the Gang of Four, the four authors of the book, “Design Patterns: Elements of Reusable Object-Oriented Software“. The four authors were Erich GammaRichard HelmRalph Johnson and John Vlissides. These 23 design patterns are categorized into three high types such as creational, structural, behavioural patterns. A software developer in his growing years would want to get hang of it in a very thorough manner as these design patterns can be seen as accepted solutions to common/recurring problems in software design. These patterns can also prove very useful for newbie developers.
  • Integration Patterns: Integration patterns primarily help integration architects and developers design and implement integration solutions more rapidly and reliably. One of the key pre-requisite for making use of these patterns is understanding of asynchronous messaging architectures.  These patterns help design solutions with various different EAI, SOA and ESB platforms. These patterns are related with topics such as some of the following:
    • Integration styles
    • Messaging systems
    • Messaging channels
    • Messaging construction
    • Message transformation,
    • Message routing etc.

    You could check details of these patterns on following page on enterprise integration patterns.

  • Web Service Patterns: These patterns help developers/architects deal with problems in relation with some of the following:
    • Creation of service API, common API styles
    • Service discovery
    • Communication between clients and services (request-response, request/acknowledge etc)
    • Request & response management (service controller, request mapper,, response mapper) etc.

    The details on all of these patterns can be found on following web page related with service design patterns. For detailed information, you may want to refer book, Service Design Patterns – Fundamental Design Solutions for SOAP/WSDL and RESTFul Web Services.

  • Database Design Patterns: Database design patterns includes patterns related with designing data model and also refactoring table/data model design. You may want to bookmark page consisting of 100 of sample data models in 50 categories. Some of the common database design patterns may look like following:
    • Foreign key pattern
    • Many-to-may relationship
    • Secure table
    • Normalized pattern
    • De-normalized patterns.

    You may want to check books such as Refactoring Databases or Data Model Patterns.

  • UI Patterns: User Interface Design patterns are recurring solutions that solve common UI design problems. These patterns fall under following categories, details of which could be found on the web page on UI Design Patterns:
    • Getting input: Patterns related to use of right UI elements in order to get the user to input data as per the context of use.
    • Navigation: The user needs to locate specific features and content and needs navigation to accomplish this.
    • Dealing with data: Data can be searched, formatted, and browsed in a variety of ways.
    • Social: Allow the user to associate, communicate, and interact with other people online.
  • Refactoring Patterns: These patterns help in code refactoring and are suggested by the master of refactoring, Martin Fowler. The details could be found on his refactoring page. These patterns help in writing quality code in place of code smells such as long classes, long methods, long parameter list, magic numbers, inappropriate naming etc.
  • Anti-Patterns: These are a set of patterns which can be described as commonly occurring solution to a problem that generates decidedly negative consequences. There are well-established anti-patterns in the area of software development (programming, software design, object-oriented design), software architect and software project management. The list of these patterns could be found from page on anti-patterns on wikipedia.
Ajitesh Kumar
Follow me

Ajitesh Kumar

I have been recently working in the area of Data analytics including Data Science and Machine Learning / Deep Learning. I am also passionate about different technologies including programming languages such as Java/JEE, Javascript, Python, R, Julia, etc, and technologies such as Blockchain, mobile computing, cloud-native technologies, application security, cloud computing platforms, big data, etc. For latest updates and blogs, follow us on Twitter. I would love to connect with you on Linkedin. Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking. Check out my other blog, Revive-n-Thrive.com
Posted in Architecture, Enterprise Architecture, Software Engg. Tagged with , , .

Leave a Reply

Your email address will not be published. Required fields are marked *