Architecture Models

This section describes three groups of architecture models aimed at optimizing the structure and design of software developments. These models specify levels of abstraction, objects relationships and guidelines to properly design functional and non-functional requirements as well as recommendations about practices to avoid negative consequences.

The main Architecture Models described in this guide are grouped into three categories:

1. Design Patterns

Design patterns describe solutions to common problems in software design. These solutions are expressed at a high level of abstraction in terms of objects and interfaces. It is like a template that can be applied in many different situations. Design patterns allow developers to implement (and reuse) simple solutions to common situations using well designed, structured and optimized code.
There are many well known and widely used software design patterns. They can be organized in 3 categories as described in SourceMaking, Design Patterns:

  • Creational Design Patterns: they provide solutions to optimize the way to create objects, instances as well as manage inheritance. Some examples of this patterns include singleton, factory method or object pool.
    See a complete list of these patterns in SourceMaking, Creational patterns.

  • Structural Design Patterns: they propose ways to compose classes and objects to create larger structures. some common patterns in this category are Facade, Composite, Decorator or Proxy.
    See a complete list of these patterns in SourceMaking, Structural patterns.

  • Behavioral Design Patterns: how to manage communication between objects. Examples: Iterator, Observer, Chain of responsibility, Visitor, etc.
    See a complete list of these patterns in SourceMaking, Behavioral patterns.

2. AntiPatterns

AntiPatterns describe common bad programming practices. They provide details of the problem, consequences and how to solve the situation. AntiPatterns usually describe situations that look like a solution but they actually lead to undesirable behaviors. It is important that developers verify that their designs or implementations do not follow some of these well known and common scenarios.

As described in SourceMaking, AntiPatterns, AntiPatterns can be grouped into 3 categories depending on the scope they apply to:

  • Software Development AntiPatterns: they describe mechanisms for refactoring, that is, ways to update and improve code structures but without changing the expected behavior. Examples of this AntiPatterns include Spaghetti Code, Cut-and-Paste, Functional Decomposition, etc.
    See a complete description of these AntiPatterns in SourceMaking, Software Development AntiPatterns.

  • Software Architecture AntiPatterns: they focus on the overall system architecture and solution design. These AntiPatterns describe scenarios related to distributed systems, systems integration, technology transfer, proprietary architectures, etc.
    See a complete description of these AntiPatterns in SourceMaking, Software Architecture AntiPatterns.

  • Software Project Management AntiPatterns: scenarios describing collaborative work, communication, roles management, iterative processes, team management, etc.
    See a complete description of these AntiPatterns in SourceMaking, Software Project Management AntiPatterns.

An additional group of AntiPattern is related to UX. UX AntiPatterns describe bad experiences of users interacting with graphic interfaces and what steps should be taken to improve user experience.
See examples of UX AntiPatterns in Envanto, The World of UX Anti-Patterns.

3. Modeling

This category includes design patterns that define commonly used principles related to software architecture, in particular how software components should be designed and how they should interact. Some common architectural patterns are the following:

  • Monolithic Application: this applications contain all code in a single codebase producing a single artifact (e.g.: one WAR file). This single artifact includes all business logic, UI components, database access, integration with other systems, etc. That means that a monolithic application can be designed as a layered architecture with specific components, libraries or services that define a structured code. This type of applications are easy to deploy or test and provide good horizontal scaling. If the application requires frequent changes and deployments or it is difficult ti understand, maintain or scale due to its complexity, then a better approach could microservices architecture.
    See more info in

  • Microservices: they are a way to split a monolithic application with the aim of deploying a loosely coupled architecture based on interconnected (micro)services. Each microservice is independent and provides a specific and complete business logic that can be developed with different technologies. We can combine microservices to implement complex functionality building a micoservices architecture easier to manage because each service can be maintained and deployed independently.
    See more info in

  • Software Oriented Architecture (SOA): this architecture encapsulates application logic within services that interact using a common communication protocol. SOA services define a logical separation of business logic so that each service provide a specific functionality that makes use of other services to build a complete logic. This is an important difference with microservices because microservices are independent and contain all necessary components to build a complete functionality (e.g.: database access, integration with APIs, etc.). In other words, to implement the same logic provided by one microsevice, we would need several SOA services.
    Another relevant difference between SOA and microservices is the communication protocol used by services to interact. SOA uses a common communication protocol (Web services) but microservices can be implemented using different technologies and rely on lightweight protocols such as REST.

  • Model-View-Controller (MVC): this common pattern separates business logic from the user interface in order to better organize code. It has three main parts:

    • Model: represents the application data. It receives requests from the controller based on user actions.
    • View: it is the user interface that renders the data coming from the model.
    • Controller: it manages user actions calling the model to get/update data and the view to render results.

    See more details of MVC pattern in Tom Dalling blog post Model View Controller Explained