If the architecture is your target... the Fundamentals are your step 0. The post will not go deep inside the concepts because they are not new. The idea is to organize the concepts in terms of architecture using the book Fundamentals of Software Architecture as a guide.

Architect vs Architecture

An application architecture define the way the data, logic and presentation are distributed between clients and servers (how end user interact with the software). The architect is involved on that definition with a different view comparing with the developer. The architect has a view focus on business.

The Architect

The authors give to us a guideline how to become an architect. The figures and videos below were done by Mark Rechards who explain it. You have to be aware of what is it, develop yourself with technical and soft skills, you will have to have domain over some technologies and at least a good understanding about others to be capable to make decisions, you have to be aware you can not solve all the problems (sometimes you have to decide what win and what lose).

Here is what is expecting from an architect:

  • Make architecture Decisions
  • Continually analyze the Architecture
  • Keep current with latest trends
  • Ensure compliance with Decisions
  • Diverse exposure and experience
  • Have business domain knowledge
  • Posses interpersonal skills
  • Understand and navigate politics

The Architecture

The Mark/Neal's book define the architecture as a combination of structure, characteristics, design principles (components) and decisions.

The Structure is regarding the type of architecture style (e.g: microservice, layred, microkernel). The design/components is a guideline to the development. The Decision is the path to follow to define the architecture trying to make it more stable and more useful the the business.

The Characteristics are regarding non-domain requirements (non-functional requirement), it can influence the structure and is critical or important to the application. The authors categorized some of them:

  • Operational: Availability, continuity, performance, recoverability, reliability, robustness, scalability
  • Structural: configurability, extensibility, installability, reuse, localization, maintainability, portability, supportability, upgradeability
  • Cross-cutting: accessibility, archivability, authentication, authorization, legal, privacy, security, supportability, usability

The ISO 25000 organized by capability.

The Measures

The modularity is the a key point in the architecture. The architect try to make the architecture more modular to facilitate the maintainability and reuse. Three concepts guide to it: cohesion, coupling and connascence.

Cohesion

Definition: the degree to which the elements inside a module belong together. Or how focused the module is on a single scope.

1 Strong Cohesion

  • Functional Cohesion: parts of a module are grouped because they all contribute to a single well-defined task of the module

2 Medium Cohesion

  • Communicational Cohesion:parts of a module are grouped because they operate on the same data
  • Procedural Cohesion: parts of a module are grouped because they always follow a certain sequence of execution
  • Sequential Cohesion:parts of a module are grouped because the output from one part is the input to another part like an assembly line

3 Weak Cohesion

  • Coincidental Cohesion: parts of a module are grouped arbitrarily; the only relationship between the parts is that they have been grouped together
  • Temporal Cohesion: parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution
  • Logical Cohesion: parts of a module are grouped because they are logically categorized to do the same thing even though they are different by nature

Coupling

Definition: coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are.

1 Tight Coupling: strong dependence, hard to change, hard to track bugs.

  • Content Coupling: one module uses the code of another module
  • Common Coupling: several modules have access to the same global data
  • External Coupling: several modules have direct access to the same external Input/Output

2 Medium Coupling: medium dependence

  • Control Coupling: data is passed that influences the internal logic of another module
  • Data Structure Coupling: multiple modules share the same data-structure.

3 Loose Coupling: low level

  • Data Coupling: two modules share the same data
  • Message Coupling: messages or commands are passed between modules
  • No Coupling: No communication between modules whatsoever

Connascence

Definition:two components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system.

1 Static: source-code-level coupling

  • Name: multiple components must agree on the name of an entity.
  • Type: multiple components must agree on the type of an entity.
  • Meaning/Convention: multiple components must agree on the meaning of particular values.
  • Position: multiple components must agree on the order of values.
  • Algorithm: multiple components must agree on a particular algorithm.

2 Dynamic

  • Types:
    1. Execution: the order of execution of multiple components is important.
    2. Timing: the timing of the execution of multiple components is important.
    3. Values: several values must change together.
    4. Identity: multiple components must reference the entity.
  • Properties: strength (how can be refactored), locality, degree





Be continued in Part 2...



Reference