Software Architecture

Starring Directed By Special Appearance Presented by With

Hi, I’m Henning

Photo: Henning Schwentner Let me tell you a story

@hschwentner Example: A Banking Domain bank account customer teller computer
transaction

@hschwentner Example: A Banking Domain computer Banking 3000

@hschwentner Good Architecture requires different ingredients ! " # $
%

@hschwentner A Short History of Software Architecture

@hschwentner Program No Architecture

@hschwentner No Architecture Mess

@hschwentner Foundations

@hschwentner Structured Programming Edsger Dijkstra Edgar Dijkstra: Go To Statement
Considered Harmful callable unit callable unit callable unit

@hschwentner Information Hiding David Parnas Programming R. Morris Techniques Editor
On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decompositions are discussed. The unconventional decomposition, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched. Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design CR Categories: 4.0 Introduction A lucid statement of the philosophy of modular programming can be found in a 1970 textbook on the design of system programs by Gouthier and Pont [1, ¶I0.23], which we quote below: 1 A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching. Usually nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means of examples, suggest some criteria which can be used in decomposing a system into modules. Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part of this material is granted, provided that reference is made to this publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Com- puting Machinery. Author's address: Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213. A Brief Status Report The major advancement in the area of modular programming has been the development of coding techniques and assemblers which (l) allow one module to be written with little knowledge of the code in another module, and (2) allow modules to be reas- sembled and replaced without reassembly of the whole system. This facility is extremely valuable for the production of large pieces of code, but the systems most often used as examples of problem systems are highly- modularized programs and make use of the techniques mentioned above. 1 Reprinted by permission of Prentice-Hall, Englewood interface implementation " #

@hschwentner Loose Coupling/ High Cohesion Ed Yourdon Larry Constantine !
in which direction?

@hschwentner Layered Architecture

@hschwentner 2 Layer Architecture Program “uses” Legend: DB

@hschwentner below The One Rule above Acyclic Dependency Principle allowed
forbidden

@hschwentner 3 Layer Architecture Presentation Logic Data

@hschwentner 4 Layer Architecture

@hschwentner Patterns Ralph Johnson Erich Gamma Richard Helm John Vlissides
a.k.a.: Gang of Four ! " # !

@hschwentner Layered Architecture Frank Buschmann et al. . . .
$

@hschwentner Strictness allowed forbidden non-strict strict

@hschwentner 4 Layer Architecture User Interface Application Domain Infrastructure

@hschwentner The Problem Infrastructure User Interface Application Domain allowed BAD!

@hschwentner The Problem Domain Infrastructure bank transaction Oracle DB Concrete
BAD!

@hschwentner Beyond Layered Architecture

@hschwentner below above From above/below to inside/outside outside inside

@hschwentner port port Hexagonal Architecture Foto: Dennis Hamilton/flickr/CC BY 2.0
http://alistair.cockburn.us/Hexagonal%2Barchitecture adapter adapter Alistair Cockburn

@hschwentner Kinds of Ports - For UI etc. - Methods
to be called - “from above” - For DB and infrastructure - Interfaces to be implemented - “from below”

@hschwentner secondary port primary port adapter adapter Kinds of Ports
Legend: Flow of control Dependency

@hschwentner Domain The Solution Domain Infrastructure bank transaction Oracle DB
Infrastructure bank transaction Oracle DB port adapter Step 1

@hschwentner uses implements Legend:

@hschwentner Dependency Inversion Depend on abstractions, not on concretions! Robert
C. Martin “Uncle Bob” !

@hschwentner Onion Architecture U I “application core” domain services domain
model infra app ture struc serv lication ices %

@hschwentner The 4 Tenets •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 Jeffrey Palermo % !

@hschwentner Designed for Testability “All application code can be compiled,
run, and tested separate from infrastructure” Easy unit tests Plays well with TDD %

Clean Architecture Robert C. Martin “Uncle Bob” interactor = use
case object U I entities DB devices w eb control use cases gate presenters lers ways

Explicit Architecture Herberto Graca $

@hschwentner Patterns Languages

@hschwentner Different Layers— Different Patterns User Interface Application Domain Infrastructure

@hschwentner Patterns for the UI Layer

@hschwentner Model—View—Controller controller view model Variants: Model—View—Presenter Model—View—Viewmodel Trygve Reenskaug
%

@hschwentner Patterns for the Domain Layer

@hschwentner Domain Logic Patterns Martin Fowler %

@hschwentner Domain Logic Patterns Martin Fowler % • Transaction Script
• Table Module • Domain Model

@hschwentner Domain-Driven Design Eric Evans !

@hschwentner Domain Modeling

@hschwentner Domain Modeling BankAccount withdraw() deposit() Amount

@hschwentner BankAccount withdraw() deposit() Amount Domain Model

@hschwentner Entity Value Object Aggregate Service Factory Repository Domain Event
Tactical Design

@hschwentner Entity Tactical Design Value Object Is it a thing?
Is it a property of a thing? Can you touch it? Is it identityless? Does it have an identity? Rules of Thumb

«Entity» BankAccount withdraw() deposit() «Value Object» Amount

@hschwentner Architecture Rules value object entity allowed forbidden

@hschwentner Expressing Architecture https://xmolecules.org

@hschwentner Patterns for the Infrastructure Layer

@hschwentner domain layer infrastructure layer Repository repository interface repository
implementation DB port adapter

@hschwentner Domain The Solution Infrastructure transaction repository Oracle DB bank
transaction repo impl Step 2 Domain Infrastructure bank transaction Oracle DB port adapter

@hschwentner Patterns for the Application Layer

@hschwentner Use Case Event Publisher Application Service Event Subscriber Application
Layer Patterns

@hschwentner Application Service domain object domain object domain object domain
object

@hschwentner Putting it all together

@hschwentner Architecture Hamburger Application Domain Infrastructure UI coarse grained

@hschwentner Architecture Hamburger fine grained model repository interface controller use
case service entity value object view data model repository implementation widget library REST frame- work transaction handling domain library programming language ORM file system access domain event

@hschwentner In the Large

@hschwentner Don’t: Build one Giant !

@hschwentner Do: Make it a Menu $%&

@hschwentner Domain-Driven Design Eric Evans !

@hschwentner Banking Domain bank computer Banking 3000

@hschwentner Banking Subdomains account processing credit lending stock trading Banking
3000

@hschwentner Big Ball of Mud Banking 3000 Big Ball of
Mud

@hschwentner Banking 3000 Strategic Design account processing credit lending stock
trading & ' (

@hschwentner Architecture Hamburger fine grained model repository interface controller use
case service entity value object view data model repository implementation domain event model repository interface controller use case service entity value object view data model repository implementation domain event

@hschwentner Example

@hschwentner LeasingNinja https://leasingninja.io

https://hschwentner.io

@hschwentner FEEDBACK

@hschwentner Bibliography Buschmann, Frank, Regine Meunier, Hans Rohnert, Peter Sommerlad,
and Michael Stal. Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Hoboken, NJ: Wiley, 1996. Cockburn, Alistair. “Hexagonal Architecture.” January 4, 2005. https://alistair.cockburn.us/hexagonal-architecture/. Dijkstra, Edsger. “Go To Statement Considered Harmful.” Communications of the ACM 11, no. 3 (March 1968): 147–48. Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley, 2004. Fowler, Martin. Patterns of Enterprise Application Architecture. Boston: Addison- Wesley, 2005. Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995. Graca, Herberto. “DDD, Hexagonal, Onion, Clean, CQRS, … How I Put It All Together.”

Henning Schwentner ⌂ https://hschwentner.io @hschwentner [email protected]

Software Architecture

Software Architecture

More Decks by Henning Schwentner

Other Decks in Programming

Featured

Transcript