Designing a Logical Architecture

Example of UP Artifact Relationships 🔗

Unified Process (UP) artifacts influence the logical architecture (LA).

The
main inputs
are the
architectural forces
captured in the supplementary specification.

The logical architecture defines the

packages

that contain the software classes.

UML Package Diagrams 🔗

A UML package diagram describes the logical architecture as part of the

design model

. The diagram can be summarized as a view in the

software architecture document

Logical Architecture and Layers 🔗

Logical architecture

The large-scale organization of
software classes
into
packages
,
subsystems
, and
layers
.

It does not determine how software is deployed to different operating system processes or physical computers on a network.

Layer

A closely related group of classes, packages, or subsystems with
cohesive responsibilities
.

Higher

layers call services in

lower

layers. Calls do not go the other way.

Common layers in object-oriented systems include the user interface (UI), application logic and domain objects, and technical services.

Strict and Relaxed Layered Architectures 🔗

Strict layered architecture

A layer calls services only in the layer directly below it.

This is common in network protocol stacks.

Relaxed layered architecture

A layer can call services in multiple lower layers.

For example, the UI layer can call both the application logic layer directly below it and elements of the technical services layer, such as logging. This is common in information systems.

What Is Software Architecture? 🔗

The discipline of creating the fundamental
structures and organization
of a software system.

Each structure includes software elements, their relationships, and their properties.

Using UML Package Diagrams 🔗

UML package diagrams

often describe the logical architecture.

They can represent layers, subsystems, and packages in the Java sense.
For example, the UI layer can be modeled as a UI package.

UML package diagrams provide a way to

group

elements.

A UML package can group many kinds of elements, including classes and use cases.
Nesting packages is common.

Package Dependencies 🔗

Package diagrams show dependencies between packages.

This lets developers identify coupling at a large scale.
A dashed arrow, called a dependency line, represents a dependency between packages.

Designing with Layers 🔗

Layers organize the overall logical structure of a system.

Separate concerns clearly by grouping related responsibilities into
distinct layers
.
Lower layers
provide
low-level
general services.
Higher layers
are specific to the
application
.
Collaboration and coupling flow from higher layers to lower layers. Avoid coupling lower layers to higher ones.

Example Layers in a Logical Architecture 🔗

User Interface (UI) layer
Application Logic layer
Domain Object layer
Business Infrastructure layer
Technical Services layer
Foundation layer

Benefits of Using Layers 🔗

Layers separate concerns, high-level and low-level work, and application-specific logic from general services.

They reduce coupling and dependencies.
They improve cohesion.
They make reuse easier.
They make the design clearer.

Related complexity can be encapsulated and decomposed. Some layers can be replaced with a new implementation.

This is generally impractical for low-level technical services or foundation layers such as java.util, but it is possible for the UI, application, and domain layers.

Lower layers contain reusable functionality.

Some layers, especially domain and technical services, can be distributed.

Logical separation makes it easier for teams to develop different parts of the system.

Domain Layers and Domain Objects 🔗

Domain objects

Create software objects with names and information drawn from the
real-world domain
, and give them responsibility for application logic.
A domain object represents something in the problem domain and contains related application or business logic.

Domain layer

The layer that uses domain objects to handle application logic.

Object-oriented developers draw on the real-world domain when creating software classes. This narrows the gap between how stakeholders understand the domain and how the software represents it.

Tiers, Layers, and Partitions 🔗

Tier

A software component in the sense of a
physical
processing node or cluster of nodes.
The term is used in expressions such as
client tier
, meaning the client computer.

Layer

A vertical division of the system.

Partition

A horizontal division within a relatively flat subsystem or layer. For example, the technical services layer can be split into partitions such as security and logging.

Model–View Separation Principle 🔗

Avoid directly connecting or coupling
non-UI objects
to
UI objects
.
Keep
application logic
out of
UI object methods
.

How SSDs, System Operations, and Layers Fit Together 🔗

In a well-designed architecture:

Objects in the
UI layer
forward or delegate requests for system operations to the
domain layer
.
The messages the UI layer sends to the domain layer are the
messages described in the system sequence diagram (SSD)
.

Example of UP Artifact Relationships 🔗

Unified Process (UP) artifacts influence the logical architecture (LA).

The
main inputs
are the
architectural forces
captured in the supplementary specification.

The logical architecture defines the

packages

that contain the software classes.

UML Package Diagrams 🔗

A UML package diagram describes the logical architecture as part of the

design model

. The diagram can be summarized as a view in the

software architecture document

Logical Architecture and Layers 🔗

Logical architecture

The large-scale organization of
software classes
into
packages
,
subsystems
, and
layers
.

It does not determine how software is deployed to different operating system processes or physical computers on a network.

Layer

A closely related group of classes, packages, or subsystems with
cohesive responsibilities
.

Higher

layers call services in

lower

layers. Calls do not go the other way.

Common layers in object-oriented systems include the user interface (UI), application logic and domain objects, and technical services.

Strict and Relaxed Layered Architectures 🔗

Strict layered architecture

A layer calls services only in the layer directly below it.

This is common in network protocol stacks.

Relaxed layered architecture

A layer can call services in multiple lower layers.

For example, the UI layer can call both the application logic layer directly below it and elements of the technical services layer, such as logging. This is common in information systems.

What Is Software Architecture? 🔗

The discipline of creating the fundamental
structures and organization
of a software system.

Each structure includes software elements, their relationships, and their properties.

Using UML Package Diagrams 🔗

UML package diagrams

often describe the logical architecture.

They can represent layers, subsystems, and packages in the Java sense.
For example, the UI layer can be modeled as a UI package.

UML package diagrams provide a way to

group

elements.

A UML package can group many kinds of elements, including classes and use cases.
Nesting packages is common.

Package Dependencies 🔗

Package diagrams show dependencies between packages.

This lets developers identify coupling at a large scale.
A dashed arrow, called a dependency line, represents a dependency between packages.

Designing with Layers 🔗

Layers organize the overall logical structure of a system.

Separate concerns clearly by grouping related responsibilities into
distinct layers
.
Lower layers
provide
low-level
general services.
Higher layers
are specific to the
application
.
Collaboration and coupling flow from higher layers to lower layers. Avoid coupling lower layers to higher ones.

Example Layers in a Logical Architecture 🔗

User Interface (UI) layer
Application Logic layer
Domain Object layer
Business Infrastructure layer
Technical Services layer
Foundation layer

Benefits of Using Layers 🔗

Layers separate concerns, high-level and low-level work, and application-specific logic from general services.

They reduce coupling and dependencies.
They improve cohesion.
They make reuse easier.
They make the design clearer.

Related complexity can be encapsulated and decomposed. Some layers can be replaced with a new implementation.

This is generally impractical for low-level technical services or foundation layers such as java.util, but it is possible for the UI, application, and domain layers.

Lower layers contain reusable functionality.

Some layers, especially domain and technical services, can be distributed.

Logical separation makes it easier for teams to develop different parts of the system.

Domain Layers and Domain Objects 🔗

Domain objects

Create software objects with names and information drawn from the
real-world domain
, and give them responsibility for application logic.
A domain object represents something in the problem domain and contains related application or business logic.

Domain layer

The layer that uses domain objects to handle application logic.

Object-oriented developers draw on the real-world domain when creating software classes. This narrows the gap between how stakeholders understand the domain and how the software represents it.

Tiers, Layers, and Partitions 🔗

Tier

A software component in the sense of a
physical
processing node or cluster of nodes.
The term is used in expressions such as
client tier
, meaning the client computer.

Layer

A vertical division of the system.

Partition

A horizontal division within a relatively flat subsystem or layer. For example, the technical services layer can be split into partitions such as security and logging.

Model–View Separation Principle 🔗

Avoid directly connecting or coupling
non-UI objects
to
UI objects
.
Keep
application logic
out of
UI object methods
.

How SSDs, System Operations, and Layers Fit Together 🔗

In a well-designed architecture:

Objects in the
UI layer
forward or delegate requests for system operations to the
domain layer
.
The messages the UI layer sends to the domain layer are the
messages described in the system sequence diagram (SSD)
.