Chapter 13 Logical Architecture

Logical Architecture Large-scale organization of classes Packages - Subsystems Layers Tools - UML package diagrams

Layer Coarse grained Cohesive responsibility Strict or relaxed E.g. User Interface or common services Strict or relaxed What are the pros and cons of each? This class focuses on one layer – application (or domain) layer.

Software Architecture Many definitions – fuzzy concept “a set of significant decision about the organization of a software system.” The framework or structure. Key aspect: Large scale, big ideas Motivation Constraints Organization Patterns Responsibilities Connections

Design with Layers Organize layers using related responsibilities Collaboration and Coupling The Layers Pattern

Why? Separation of concerns Encapsulate complexity Eliminate inter-twined code Features and fixes are contained Replaceable layer Reusable function Team organization Up-front investment reduces maintenance costs.

Domain layer vs. Application Layer Application layer organization Create domain objects that encapsulate application logic (Domain Layer) “Create software objects with names and information similar to the real-world domain and assign application logic responsibilities to them.” Domain layer != Domain model “Designing objects this way leads to the application logic layer being more accurately called the domain layer of the architecture – the layer that contains domain objects.” Lowers the representational gap.”

Terminology Tier - current usage: physical nodes Layers Partitions - parallel division of layers See Figs 13.6 and 13.7

SSD, System Operations, Layers When there is a UI layer: SSD shows operations to the UI Layer Do not couple UI objects directly to application/domain objects. Do not put application data into UI objects. Model (domain) vs UI (view) separation.

Summary Separation into layers is a common first step In Architecture centric design, this flows from the software architecture