Book Image

arc42 by Example

By : Dr. Gernot Starke, Michael Simons, Stefan Zörner, Ralf D. Müller
Book Image

arc42 by Example

By: Dr. Gernot Starke, Michael Simons, Stefan Zörner, Ralf D. Müller

Overview of this book

When developers document the architecture of their systems, they often invent their own specific ways of articulating structures, designs, concepts, and decisions. What they need is a template that enables simple and efficient software architecture documentation. arc42 by Example shows how it's done through several real-world examples. Each example in the book, whether it is a chess engine, a huge CRM system, or a cool web system, starts with a brief description of the problem domain and the quality requirements. Then, you'll discover the system context with all the external interfaces. You'll dive into an overview of the solution strategy to implement the building blocks and runtime scenarios. The later chapters also explain various cross-cutting concerns and how they affect other aspects of a program.

Related Content you might be interested in

Current Title:

Small book image
arc42 by Example
Dr. Gernot Starke | Michael Simons | Stefan Zörner | Ralf D. Müller
Oct, 2019 | 236 pages
No titles found
Table of Contents (9 chapters)
About the Book
About the Book
About the Authors
Learning Objectives
Audience
Approach
Conventions
Free Chapter
1
Acknowledgements
Acknowledgements
2
I - Introduction
I - Introduction
I.1 What is arc42?
I.2 Why This Book?
I.3 What This Book is Not
I.4 An Overview of Examples
I.5 A table of arc42 Topics
3
II - HTML Sanity Checking
II - HTML Sanity Checking
II.1 Introduction and Goals
II.2 Constraints
II.3 Context
II.4 Solution Strategy
II.5 Building Block View
II.6 Runtime View
II.7 Deployment View
II.8 Crosscutting Concepts
II.9 Design Decisions
II.10 Quality Scenarios
II.11 Risks and Technical Debt
II.12 Glossary
4
III - Mass Market Customer Relationship Management
III - Mass Market Customer Relationship Management
III.1 Introduction and Requirements
III.2 Constraints
III.3 Context
III.4 Solution Strategy
III.5 Building Blocks
III.6 Runtime View
III.7 Deployment View
III.8 Cross cutting Concepts
III.9 Architecture Decisions
III.10 Quality Scenarios
III.11 Risks
III.12 Glossary
5
IV - biking2
IV - biking2
IV.1 Introduction and Requirements
IV.2 Architecture Constraints
IV.3 System Scope and Context
IV.4 Solution Strategy
IV.5 Building Blocks-Level 1
IV.6 Runtime View
IV.7 Deployment View
IV.8 Technical and Crosscutting Concepts
IV.9 Architecture Decisions
IV.10 Quality Scenarios
IV.11 Risks
IV.12 Glossary
6
V - DokChess
V - DokChess
V.1 Introduction and Requirements
V.2 Constraints
V.3 Context
V.4 Solution Strategy
V.5 Building Block View
V.6 Runtime View
V.7 Deployment View
V.8 Technical and Cross cutting Concepts
V.9 Design Decisions
V.10 Quality Scenarios
V.11 Risks
V.12 Glossary
7
VI - docToolchain
VI - docToolchain
VI.1 Introduction and Goals
VI.2 Architecture Constraints
VI.3 System Scope and Context
VI.4 Solution Strategy
VI.5 Building Block View
VI.6 Runtime View
VI.7 Deployment View
VI.8 Cross cutting Concepts
VI.9 Design Decisions
VI.10 Quality Requirements
VI.11 Risks and Technical Debts
VI.12 Glossary
8
VII - macOS Menu Bar Application
VII - macOS Menu Bar Application

V.8 Technical and Cross cutting Concepts

This section describes general structures and system-wide aspects. It also presents various technical solutions.

8.1 Dependencies between Modules

DokChess invites developers to experiment and to extend the engine (V 1.2 Quality Goals). In order to do so, the modules are loosely coupled. DokChess modules are implementations of Java interfaces. Java classes that require parts signal this with appropriate methods set"Module"("Interface" …). They don't take care of resolving a dependency, for instance, by using a factory. Instead, the client resolves the dependencies by creating suitable implementations with new and putting them together with setter methods, also known as Dependency Injection (DI).

Interfaces and DI enable alternative implementations within DokChess. Adding functionality with the help of the decorator pattern (Gamma+94) is possible as well. Furthermore, aspect-oriented programming (AOP) solutions, which rely...

Previous Section
End of Section 9
Next Section