Software Architecture

Question 1

Package Cohesion Principles, by Robert C. Martin:

Answer 1

REP – The Release Reuse Equivalency Principle
The granule of reuse is the granule of release

CCP – The Common Closure Principle
Classes that change together are packaged together

CRP – The Common Reuse Principle
Classes that are used together are packaged together

Question 2

Package Coupling Principles, by Robert C. Martin:

Answer 2

ADP – The Acyclic Dependencies Principle
The dependency graph of packages must have no cycles

SDP – The Stable Dependencies Principle
Depend in the direction of stability

SAP – The Stable Abstractions Principle
Abstractness increases with stability

Question 3

Architectural styles

Answer 3

The application design at the highest level of abstraction.

Tell us, in very broad strokes, how to organize our code. It’s the highest level of granularity and it specifies layers, high-level modules of the application and how those modules and layers interact with each other, the relations between them.

Question 4

Architectural Patterns

Answer 4

Is a way to implement an Architectural Style.

A pattern is a recurring solution to a recurring problem. In the case of Architectural Patterns, they solve the problems related to the Architectural Style.

Question 5

Design Patterns

Answer 5

A way to solve a localised problem.

Differ from Architectural Patterns in their scope, they are more localised, they have less impact on the code base, they impact a specific section of the code base.

Question 6

The modern monolith

Answer 6

Having a monolithic Architectural Style simply means that all of the application code is deployed and run as a single process on a single node. We assume, it is using modules and components, although it is in fact often not the case.

Regarding the first one, deployed, it means that it doesn’t matter where the code is physically stored if it is organised in one or several repositories, but how it is organised at runtime. Regarding the second keyword, node, it means that it is still a monolith if we deploy the application to several servers, as in a horizontal scaling context.

In a single node server, all of the modules in a monolith are assembled to the same memory image, which is run as a single process on a single node. Communication is done through standard procedure calls through the same stack and heap. It’s the single memory image makes the application monolithic. If you are running modules in different processes, you’re doing IPC. Because modules fall into different process boundaries, you’ll start facing distributed computing challenges. That’s getting into microservice territory.

Question 7

The modern monolith stops being good enough when we need:

Answer 7

Independent scalability of different domain components;

Different components or modules to be written in different programming languages;

Independent deployability, maybe because we have a release rate higher than the deployment pipeline can handle for one code base, causing the deployment of a release to be slow because it needs to wait for the deployment of other releases, or even causing the deployment queue to grow faster than it is consumed.

Question 8

EBI.Entity

Answer 8

The Entity objects hold the data used by the system and all the behaviour naturally coupled to this data. Each Entity object represents a concept relevant to the problem domain and wich holds identity and resilient (persistent) data.

Question 9

EBI.Boundary (Interface)

Answer 9

The Boundary objects model the interface with the system. Everything concerning the interface of the system is placed in an interface object.

Question 10

EBI.Interactor (Control)

Answer 10

Behaviour that remains after the Interface objects and Entity objects have obtained their parts will be placed in the control objects.

Question 11

DDD layers are…

Answer 11

User Interface
Responsible for drawing the screens the users use to interact with the application and translating the user’s inputs into application commands.

Application Layer
Orchestrates Domain objects to perform tasks required by the users: the Use Cases. It does not contain business logic. This layer is where the Application Services belong, as they are the containers where the use case orchestration happens.

Domain Layer
This is the layer that contains all the business logic, the Domain Services, Entities, Events and any other object type that contains Business Logic.

Infrastructure
The technical capabilities that support the layers above, ie. persistence or messaging.

Question 12

Bounded context

Answer 12

Define a context where an isolated part of the model applies.

Question 13

Anti-Corruption Layer

Answer 13

An anti-corruption layer is basically a middleware between two subsystems. It is used to isolate the two subsystems, making them depend on the anti-corruption layer instead of depending directly on each other.

Question 14

Anti-Corruption Layer main concerns are…

Answer 14

Adapting subsystems APIs to what the client subsystems need;

Translating data and commands between subsystems;

Establish communication in one or several directions, as needed

Question 15

Shared Kernel

Answer 15

In some situations, despite our desire to have completely isolated and decoupled components, it makes sense for some domain code to be shared by multiple components.

This will allow components to stay decoupled from each other, although coupled to that same shared code, the shared kernel.

Question 16

Generic Subdomain

Answer 16

A subdomain that is not specific to our application, it could be used in any similar application.

Question 17

Subdomain

Answer 17

A very well isolated part of the domain.

Question 18

Adapters Architecture (aka Hexagonal Architecture)

Answer 18

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

Goal: isolate the business logic from the delivery mechanisms and tools used by the system.

Question 19

Adapter

Answer 19

A class that transforms (adapts) an interface into another. It depends on a specific tool and a specific port (by implementing an interface).

Question 20

Primary or Driving Adapters

Answer 20

The ones to start some action on the application. Both the port and its concrete implementation (the use case) belong inside the application.

Question 21

Secondary or Driven Adapters

Answer 21

The ones representing the connections to the backend tools. They always react to an action of a primary adapter. The port belongs inside the application, but its concrete implementation belongs outside

Question 22

Port

Answer 22

Consumer agnostic entry and exit point to/from the application. In many languages, it will be an interface.
is designed to fit the business logic needs, so it doesn’t depend on a specific adapter or tool.

Question 23

Layered Architecture consists of …

Answer 23

Presentation
Application
Domain
Persistence

Question 24

Key tenets of Onion Architecture:

Answer 24

The application is built around an independent object model

Inner layers define interfaces. Outer layers implement interfaces

Direction of coupling is toward the center

All application core code can be compiled and run separate from infrastructure

Any outer layer can directly call any inner layer, which does not break the coupling direction and avoids creating proxy methods and even proxy classes that contain no business logic, just for the sake of complying with some layering scheme

Question 25

Сore objectives behind Clean Architecture (the same as for Ports & Adapters (Hexagonal) and Onion Architectures):

Answer 25

Independence of tools
Independence of delivery mechanisms (UI)
Testability in isolation

Question 26

Dependency Inversion Principle at the architectural level

Answer 26

Nothing in an inner circle can know anything at all about something in an outer circle. Furthermore, when we pass data across a boundary, it is always in the form that is most convenient for the inner circle.

Question 27

Three cases in which to use events:

Answer 27

To decouple components
To perform async tasks
To keep track of state changes (audit log)

Question 28

Martin Fowler identifies three different types of event patterns:

Answer 28

Event Notification
Event-Carried State Transfer
Event-Sourcing

Question 29

All event patterns share the same key concepts:

Answer 29

Events communicate that something has happened (they occur after something)

Events are broadcasted to any code that is listening (several code units can react to an event)

Question 30

Event Notification

Answer 30

The event carries minimal data.

It carries only enough data for the listener to know what happened and carry out their code, usually just entity ID(s) and maybe the date and time that the event was created.

Question 31

Event-Carried State Transfer

Answer 31

The event carries the whole new version of the data with it.

Question 32

Event-Sourcing

Answer 32

Storing the Entity state changes and computing the Entity state from those changes.

Question 33

Event store

Answer 33

Becomes the principal source of truth, and the system state is purely derived from it. For programmers, the best example of this is a version-control system. The log of all the commits is the event store and the working copy of the source tree is the system state.

Question 34

Reversal Transaction

Answer 34

Event, in the event stream, that reverses the event that we would like to delete.

Question 35

Projection

Answer 35

The computation of the events in an event stream, from and to specific moments. A snapshot, or the current state of an entity, fits the definition of a projection.

But the most valuable idea in the concept of projections, is that we can analyse the “behaviour” of Entities during specific periods of time, which allows us to make educated guesses about the future.

Question 36

Martin Fowler identifies 3 types of code changes:

Answer 36

New features
Bug fixes
Temporal logic

Question 37

Advice for using events:

Answer 37

Keep events dumb, knowing only about the state change and not how it was decided.

Interactions with external systems should not depend on these events, this way we can safely replay events without the danger of retriggering external logic and we don’t need to ensure the reply from the external system is the same as when the event was played originally.

Question 38

Command Pattern

Answer 38

Moves us away from a data-centric application and into a process-centric application, who has domain knowledge and application processes knowledge.

Question 39

Command Bus

Answer 39

Capable of receiving a Command and figure out what handler can handle it.

Question 40

Command

Answer 40

Simple DTO to hold the data.

Question 41

Handler

Answer 41

Have a method to trigger the logic execution.

Question 42

SOA focuses on only a few concepts and doesn’t give any prescription on how to implement them:

Answer 42

Composability of user-facing applications;
Reusable Business Services;
Technology stack independent;
Autonomy (independent evolution, scalability & deployability).

Question 43

CORBA (Common Object Request Broker Architecture)

Answer 43

The CORBA standard was implemented by several vendors and aimed at providing:

Platform neutral Remote Procedure Call;
Transactions (also remote transactions!!);
Security;
Events;
Programming language independence;
OS independence;
Hardware independence;
Isolation from data-transfer/communication details;
Data typing through an Interface Definition Language (IDL).

Question 44

Web Services

Answer 44

Are designed as bounded contexts for business sub-domains, abstracting the implementation from the conceptual service they provide.

Question 45

The primary duties of an ESB (Enterprise Service Bus) are:

Answer 45

Monitor and control routing of message exchange between services;
Resolve translation of messages between communicating service components;
Control deployment and versioning of services;
Marshal use of redundant services;
Cater for commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service;

It was born into a context of stand-alone applications that needed to be integrated in order to achieve an enterprise-wide distributed application.

Question 46

Microservices Architecture main idea is…

Answer 46

Creating one global enterprise application from several more specific business domain applications. It was born into a context of fast paced and ever changing businesses who (mostly) create their own cloud applications from scratch.

Small autonomous services that work together, modeled around a business domain.

Question 47

Sam Newman, the author of Building Microservices, identifies 8 principles of a Microservices Architecture:

Answer 47

Services are modeled around business domains
Culture of automation
Hide implementation details
Decentralise all the things
Deploy independently
Consumer first
Isolate failure
Highly observable

Question 48

Inversion of control principle

Answer 48

The direction of dependencies is towards the center.

Question 49

The basic principles that form the bedrock of good software are…

Answer 49

Simplicity, which keeps programs short and manageable;

Clarity, which makes sure they are easy to understand, for people as well as machines;

Generality, which means they work well in a broad range of situations and adapt well as new situations arise;

Automation, which lets the machine do the work for us, freeing us from mundane tasks.