Clean Architecture with NET 1st Edition Esposito

pdf download

https://textbookfull.com/product/clean-architecture-with-net-1st-
edition-esposito/

Download more ebook from https://textbookfull.com

We believe these products will be a great fit for you. Click
the link to download now, or visit textbookfull.com
to discover even more!

Clean Architecture With net Developer Reference 1st

Edition Esposito Dino

https://textbookfull.com/product/clean-architecture-with-net-
developer-reference-1st-edition-esposito-dino/

Programming Microsoft ASP NET MVC Dino Esposito

https://textbookfull.com/product/programming-microsoft-asp-net-
mvc-dino-esposito/

Get Your Hands Dirty on Clean Architecture Build clean

applications with code examples in Java 2nd Edition Tom
Hombergs

https://textbookfull.com/product/get-your-hands-dirty-on-clean-
architecture-build-clean-applications-with-code-examples-in-
java-2nd-edition-tom-hombergs/

Clean Cooking: Healthy Eating is Easy with Delicious

Clean Recipes (2nd Edition) Booksumo Press

https://textbookfull.com/product/clean-cooking-healthy-eating-is-
easy-with-delicious-clean-recipes-2nd-edition-booksumo-press/
Pro C# 7 with .NET and .NET Core Andrew Troelsen

https://textbookfull.com/product/pro-c-7-with-net-and-net-core-
andrew-troelsen/

Arduino Programming with .NET and Sketch 1st Edition

Agus Kurniawan

https://textbookfull.com/product/arduino-programming-with-net-
and-sketch-1st-edition-agus-kurniawan/

Arduino Programming with .NET and Sketch 1st Edition

Agus Kurniawan

https://textbookfull.com/product/arduino-programming-with-net-
and-sketch-1st-edition-agus-kurniawan-2/

Modern Data Access with Entity Framework Core: Database

Programming Techniques for .NET, .NET Core, UWP, and
Xamarin with C# 1st Edition Holger Schwichtenberg

https://textbookfull.com/product/modern-data-access-with-entity-
framework-core-database-programming-techniques-for-net-net-core-
uwp-and-xamarin-with-c-1st-edition-holger-schwichtenberg/

Modern Data Access with Entity Framework Core: Database

Programming Techniques for . NET, . NET Core, UWP, and
Xamarin with C# 1st Edition Holger Schwichtenberg

https://textbookfull.com/product/modern-data-access-with-entity-
framework-core-database-programming-techniques-for-net-net-core-
uwp-and-xamarin-with-c-1st-edition-holger-schwichtenberg-2/
Clean Architecture
with .NET

Dino Esposito
Clean Architecture with .NET Editor-in-Chief
Published with the authorization of Microsoft Corporation by: Brett Bartow

Pearson Education, Inc., Hoboken, New Jersey Executive Editor

Copyright © 2024 by Dino Esposito. Loretta Yates

All rights reserved. This publication is protected by copyright, and permission Associate Editor
must be obtained from the publisher prior to any prohibited reproduction, Shourav Bose
storage in a retrieval system, or transmission in any form or by any means,
electronic, mechanical, photocopying, recording, or likewise. For information Development Editor
regarding permissions, request forms, and the appropriate contacts within the Kate Shoup
Pearson Education Global Rights & Permissions Department, please visit
www.pearson.com/permissions. Managing Editor
No patent liability is assumed with respect to the use of the information con- Sandra Schroeder
tained herein. Although every precaution has been taken in the preparation
Senior Project Editor
of this book, the publisher and author assume no responsibility for errors or
omissions. Nor is any liability assumed for damages resulting from the use of Tracey Croom
the information contained herein. Copy Editor
ISBN-13: 978-0-13-820328-3 Dan Foster
ISBN-10: 0-13-820328-8
Indexer
Library of Congress Control Number: 2024930932
Ken Johnson
$PrintCode
Proofreader
Trademarks
Jennifer Hinchliffe
Microsoft and the trademarks listed at http://www.microsoft.com on the
“Trademarks” webpage are trademarks of the Microsoft group of companies. Technical Editor
All other marks are property of their respective owners. Milan Jovanovic
Warning and Disclaimer Editorial Assistant
Every effort has been made to make this book as complete and as accurate as Cindy Teeters
possible, but no warranty or fitness is implied. The information provided is on
an “as is” basis. The author, the publisher, and Microsoft Corporation shall have Cover Designer
neither liability nor responsibility to any person or entity with respect to any Twist Creative, Seattle
loss or damages arising from the information contained in this book or from
the use of the programs accompanying it. Compositor
codeMantra
Special Sales
For information about buying this title in bulk quantities, or for special sales Graphics
opportunities (which may include electronic versions; custom cover designs; codeMantra
and content particular to your business, training goals, marketing focus, or
branding interests), please contact our corporate sales department at
corpsales@pearsoned.com or (800) 382-3419.
For government sales inquiries, please contact
governmentsales@pearsoned.com.
For questions about sales outside the U.S., please contact intlcs@pearson.com.
Contents at a Glance

Introduction xv

PART I THE HOLY GRAIL OF MODULARITY

CHAPTER 1 The quest for modular software architecture 3
CHAPTER 2 The ultimate gist of DDD 23
CHAPTER 3 Laying the ground for modularity 47

PART II ARCHITECTURE CLEANUP

CHAPTER 4 The presentation layer 65

CHAPTER 5 The application layer 91
CHAPTER 6 The domain layer 133
CHAPTER 7 Domain services 169
CHAPTER 8 The infrastructure layer 189

PART III COMMON DILEMMAS

CHAPTER 9 Microservices versus modular monoliths 219

CHAPTER 10 Client-side versus server-side 255
CHAPTER 11 Technical debt and credit 285

Index 301
This page intentionally left blank
Contents
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

PART I THE HOLY GRAIL OF MODULARITY

Chapter 1 The quest for modular software architecture 3

In the beginning, it was three-tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Core facts of a three-tier system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Layers, tiers, and modularization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

The DDD canonical architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

The proposed supporting architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Adding more to the recipe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Different flavors of layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Hexagonal architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Clean architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Feature-driven architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 2 The ultimate gist of DDD 23

Design driven by the domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Strategic analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Tactical design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
DDD misconceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Tools for strategic design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Ubiquitous language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A domain-specific language vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . 29
Building the glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Keeping business and code in sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

The bounded context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Making sense of ambiguity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

v

 Devising bounded contexts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

The context map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Upstream and downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
An example context map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
An example deployment map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 3 Laying the ground for modularity 47

Aspects and principles of modularization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Separation of concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Loose coupling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Reusability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Dependency management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Testability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Applying modularization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
The presentation layer: interacting with the outside world. . . . . . . . . 51
The application layer: processing received commands. . . . . . . . . . . . . 51
The domain layer: representing domain entities. . . . . . . . . . . . . . . . . . 52
The data/infrastructure layer: persisting data . . . . . . . . . . . . . . . . . . . . 52

Achieving modularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
More modularity in monoliths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Introducing microservices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
The simplest solution ever . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Maintainability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Designing for testability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

PART II ARCHITECTURE CLEANUP

Chapter 4 The presentation layer 65

Project Renoir: the final destination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Introducing the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
The abstract context map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

vi Contents
 Designing the physical context map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Business requirements engineering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Breakdown of software projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Event-based storyboards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Fundamental tasks of Project Renoir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Boundaries and deployment of the presentation layer. . . . . . . . . . . . . . . . . . 79

Knocking at the web server’s door. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
ASP.NET application endpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Presentation layer development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Connecting to business workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Front-end and related technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
API-only presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 5 The application layer 91

An architectural view of Project Renoir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
The access control subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
The document-management subsystem. . . . . . . . . . . . . . . . . . . . . . . . . 94
Project Renoir in Visual Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Task orchestration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
What is a task, anyway?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
An example distributed task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
An example task in Project Renoir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Data transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
From the presentation layer to the application layer. . . . . . . . . . . . . 100
From the application layer to the persistence layer . . . . . . . . . . . . . . 104

Implementation facts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Outline of an application layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Propagating application settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Handling and throwing exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Contents vii
 Caching and caching patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Injecting SignalR connection hubs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Boundaries and deployment of the application layer . . . . . . . . . . . . . . . . . . 129

The dependency list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Deployment options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Chapter 6 The domain layer 133

Decomposition of the domain layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
The business domain model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Helper domain services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Devising a domain model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Shifting focus from data to behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Life forms in a domain model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
The domain model in Project Renoir. . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

The hitchhiker’s guide to the domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Treating software anemia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Common traits of an entity class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Rules of etiquette. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Style conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Writing truly readable code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Chapter 7 Domain services 169

What is a domain service, anyway? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
The stateless nature of domain services. . . . . . . . . . . . . . . . . . . . . . . . . . 170
Marking domain service classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Domain services and ubiquitous language. . . . . . . . . . . . . . . . . . . . . . . 171
Data access in domain services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Data injection in domain services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Common scenarios for domain services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Determining the loyalty status of a customer. . . . . . . . . . . . . . . . . . . . . 173
Blinking at domain events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

viii Contents
 Sending business emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Service to hash passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Implementation facts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Building a sample domain service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Useful and related patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
The REPR pattern adapted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Open points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Are domain services really necessary? . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Additional scenarios for domain services. . . . . . . . . . . . . . . . . . . . . . . . . 187

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Chapter 8 The infrastructure layer 189

Responsibilities of the infrastructure layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Data persistence and storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Communication with external services. . . . . . . . . . . . . . . . . . . . . . . . . . 190
Communication with internal services . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Implementing the persistence layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Repository classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Using Entity Framework Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Using Dapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Hosting business logic in the database. . . . . . . . . . . . . . . . . . . . . . . . . . 207

Data storage architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Introducing command/query separation. . . . . . . . . . . . . . . . . . . . . . . . 208
An executive summary of event sourcing . . . . . . . . . . . . . . . . . . . . . . . . 213
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

PART III COMMON DILEMMAS

Chapter 9 Microservices versus modular monoliths 219

Moving away from legacy monoliths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Not all monoliths are equal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Potential downsides of monoliths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Facts about microservices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Contents ix
 Early adopters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Tenets of a microservices architecture and SOA . . . . . . . . . . . . . . . . . 224
How big or small is “micro”?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
The benefits of microservices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
The gray areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Can microservices fit all applications?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

The big misconception of big companies . . . . . . . . . . . . . . . . . . . . . . . 235
SOA and microservices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Are microservices a good fit for your scenario?. . . . . . . . . . . . . . . . . . 237
Planning and deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Modular monoliths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

The delicate case of greenfield projects. . . . . . . . . . . . . . . . . . . . . . . . . 246
Outlining a modular monolith strategy for new projects. . . . . . . . . 247
From modules to microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Chapter 10 Client-side versus server-side 255

A brief history of web applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
The prehistoric era. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
The server-scripting era. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
The client-scripting era. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260

Client-side rendering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

The HTML layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
The API layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Toward a modern prehistoric era. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Server-side rendering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Front-end–back-end separation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
ASP.NET front-end options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
ASP.NET Core versus Node.js. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
The blocking/non-blocking saga. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

x Contents
Chapter 11 Technical debt and credit 285
The hidden cost of technical debt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Dealing with technical debt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Ways to address debt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Debt amplifiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

The hidden profit of technical credit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

The theory of broken windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
The power of refactoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Do things right, right away. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Index 301

Contents xi
This page intentionally left blank
 Acknowledgments

As hair thins and grays, memories return of when I was the youngest in every meeting
or conference room. In 30 years of my career, I witnessed the explosion of Windows as
an operating system, the rise of the web accompanied by websites and applications, and
then the advent of mobile and cloud technologies.

Several times, I found myself having visions related to software technology devel-
opments, not too far from what happened a few years later. At other times, I surprised
myself by formulating personal projects halfway between dreams and ambitious goals.

The most unspoken of all is the desire to travel the world, speaking at international
conferences without the pressure to talk about what is cool and trendy but only about
what I have seen and made work—without mincing words and without filters or
reservations. To do this, I needed to work—finally—daily on the development of real
applications that contributed to some kind of business and simplified the lives of some
kind of audience.

Thanks to Crionet and KBMS Data Force, this is now a reality.

After many years, I have a full-time position (CTO of Crionet), a team of people grown
in a few years from juniors to bold and capable professionals, and the will to share with
everyone a recipe for making software that is neither secret nor magical.

I have nothing to sell; only to tell. And this book is for those who want to listen.

This book is for Silvia and Francesco.

This book is for Michela.

This book is for Giorgio and Gaetano.

This book was made possible by Loretta and Shourav and came out as you’re getting
it thanks to Milan, Tracey, Dan, and Kate.

This book is my best until the next one!

xiii

This page intentionally left blank
 Introduction

I graduated in Computer Science in the summer of 1990. At the time, there were not
many places in Europe to study computers. The degree course was not even set up with
its own Computer Science faculty but was an extension of the more classical faculty of
Mathematics, Physics, and Natural Sciences. Those with strong computer expertise in the
1990s were really cool people—in high demand but with unclear career paths. I started
as a Windows developer. Computer magazines were popular and eagerly awaited every
month. I dreamt of writing for one of them. I won the chance to do it once and liked it so
much that I’m still doing it today, 30 years later.

My passion for sharing knowledge was so intense that five years after my first serious
developer job it became my primary occupation. For over two decades all I did was write
books and articles, speak at conferences, teach courses, and do occasional consulting.
Until 2020, I had a very limited exposure to production code and the routine of day-by-
day development. Yet, I managed to write successful books for those who were involved
in real-world projects.

Still, in a remote area of my mind was a thorny doubt: Am I just a lecture type of pro-
fessional or am I also an action person? Will I be able to ever build a real-world system?
The pandemic and other life changes brought me to ultimately find an answer.

I faced the daunting task of building a huge and intricate system in a fraction of the
time originally scheduled that the pandemic sharply cut off. No way to design, be agile,
do testing and planning—the deadline was the only certain thing. I resorted to doing—
and letting a few other people do—just what I taught and had discovered while teaching
for years. It worked. Not just that. Along the way, I realized that the approach we took
to build software, and related patterns, also had a name: clean architecture. This book is
the best I know and have learned in three years of everyday software development after
over two decades of learning, teaching, and consulting.

In our company, we have several developers who joined as juniors and have grown
up using and experimenting with the content of this book. It worked for us; I hope it will
work for you, too!

xv

 Who should read this book
Software professionals are the audience for this book, including architects, lead develop-
ers, and—I would say, especially—developers of any type of .NET applications. Everyone
who wants to be a software architect should find this book helpful and worth the cost.
And valid architects are, for the most part, born developers. I strongly believe that the
key to great software passes through great developers, and great developers grow out
of good teachers, good examples, and—hopefully—good books and courses.

Is this book only for .NET professionals? Although all chapters have a .NET flavor, most
of the content is readable by any software professional.

Assumptions
This book expects that you have at least a minimal understanding of .NET development and
object-oriented programming concepts. A good foundation in using the .NET platform and
knowledge of some data-access techniques will also help. We put great effort into making
this book read well. It’s not a book about abstract design concepts, and it’s not a classic archi-
tecture book either, full of cross-references or fancy strings in square brackets that hyperlink
to some old paper listed in a bibliography at the end of the book. It’s a book about building
systems in the 2020s and facing the dilemmas of the 2020s, from the front end to the back
end, passing through cloud platforms and scalability issues.

This book might not be for you if…

If you’re seeking a reference book or you want to find out how to use a given pattern or
technology then this book might not for you. Instead, the goal is sharing and
transferring knowledge so that you know what to do at any point. Or, at least, you now
know what other guys—Dino and team—did in an analogous situation.

Organization of this book

In all, modern software architecture has just one precondition: modularity. Whether you
go with a distributed, service-oriented structure, a microservices fragmented pattern,
or a compact monolithic application, modularity is crucial to build and manage the
codebase and to further enhance the application following the needs of the business.
Without modularity, you can just be able to deliver a working system once, but it will be
hard to expand and update it.

xvi Introduction
 Part I of this book, titled “The Holy Grail of modularity,” lays the foundation of soft-
ware modularity, tracing back the history of software architecture and summarizing the
gist of domain-driven design (DDD)—one of the most helpful methodologies for break-
ing down business domains, though far from being an absolute necessity in a project.

Part II, “Architecture cleanup,” is about the five layers that constitute, in the vision of
this book, a “clean” architecture. The focus is not much on the concentric rendering of
the architecture, as popularized by tons of books and articles, but on the actual value
delivered by constituent layers: presentation, application, domain, domain services, and
infrastructure.

Finally, Part III, “Common dilemmas,” focuses on three frequently faced stumbling
blocks: monoliths or microservices, client-side or server-side for the front end, and the
role and weight of technical debt.

Downloads: reference application

Part II of the book describes a reference application, Project Renoir, whose entire code-
base is available on GitHub at:

https://github.com/Youbiquitous/project-renoir

A zipped version of the source code is also available for download at

MicrosoftPressStore.com/NET/download.

Note The reference application requires .NET 8 and is an ASP.NET application

with a Blazor front end. It uses Entity Framework for data access and assumes a
SQL Server (any version) database.

Errata, updates, and book support

We’ve made every effort to ensure the accuracy of this book and its companion content.
You can access updates to this book—in the form of a list of submitted errata and their
related corrections—at:

MicrosoftPressStore.com/NET/errata

If you discover an error that is not already listed, please submit it to us at the same
page.

Introduction xvii
 For additional book support and information, please visit
MicrosoftPressStore.com/Support.

Please note that product support for Microsoft software and hardware is not offered
through the previous addresses. For help with Microsoft software or hardware, go to
http://support.microsoft.com.

Stay in touch
Let’s keep the conversation going! We’re on Twitter: http://twitter.com/MicrosoftPress

xviii Introduction
 PAR T I

The Holy Grail of

modularity

CHAPTER 1 The quest for modular software architecture . . . . . . . 3

CHAPTER 2 The ultimate gist of DDD . . . . . . . . . . . . . . . . . . . . . . . . . 23

CHAPTER 3 Laying the ground for modularity . . . . . . . . . . . . . . . . 47

1

This page intentionally left blank
CHAPTER 1

The quest for modular software

architecture

The purpose of software engineering is to control complexity, not to create it.

—Dr. Pamela Zave, Princeton University

S oftware as we know it today, in the middle of the 2020s, is the waste product of a more profound
learning and transformation process whose origins are deeply rooted within the history of logic and
mathematics. Since the 17th century, some of the world’s greatest minds focused on building a coher-
ent, logical system that could allow for mechanical reasoning. The proof that it was not just dreaming
came only in the 1930s with Kurt Gödel’s Theorem of Incompleteness. From there, Alan Turing and John
Von Neumann started engineering physical machines.

None of them, though, ever dreamed of anything near the software of today. Their goal was to
mechanize the human way of reasoning, as simple and ambitious as that may still sound. The early
“thinking” machines of the 1950s were iron monoliths made of valves, pistons, and cables—wired hard-
ware, no more, no less. John Von Neumann had the intuition that instructions were better separated
from hardware so that the same machine could do different things, such as mathematics and text pro-
cessing. The popular “von Neumann architecture” ultimately refers to having a stored program whose
instructions are fetched one by one and processed sequentially.

Software gained its own dignity and identity only at the end of the 1960s, about the time human-
kind landed on the moon. The first reported use of the term “software engineering” dates to the
mid-1960s. Nobody ever managed to create the software; rather, it emerged as a side effect—or waste
product—of more ambitious research. Separating hardware from software was the first step of modu-
larization ever experienced in computer science.

It seems that humans have always approached solving problems using an end-to-end sequence of
steps, with references and interconnections between states set and exchanged as needed to reach a
solution. As spaghetti code has shown, software is no exception.

Note The quest for modularization started as early as software itself and soon moved from
the level of application code to the level of application architecture.

3

In the beginning, it was three-tier
The first historical example of a software architecture that expands beyond the realm of a single
computer was proposed in the 1960s with the IBM 360 system. The idea was that a remote workstation
could send the central mainframe a request to execute some non-interactive data-processing opera-
tion, called a job. Further refined in successive years, the model became universally known as client/
server architecture after the paper “Separating Data from Function in a Distributed File System,” written
by a group of Xerox PARC computer scientists in 1978. Client/server was the canonical way of building
business applications when I got my first job as a developer right after graduating from university.

Note Von Neumann broke up the computer monolith into hardware and software com-
ponents, and IBM and Xerox researchers broke the software monolith into client and server
components.

We all heartily welcomed three-tier architecture in the late 1990s. At the time, the definition of an
additional software tier, which took on some client liabilities and some server tasks, proved necessary
to better handle the complexity of the (new) applications being built at a fairly rapid pace.

Note In the previous paragraph, I deliberately placed the adjective “new” in parentheses
because it referred to applications planned and built using the three-tier architecture before
the commercial explosion of the internet. At the time, colossus line-of-business applica-
tions (for example, financial, telecom, government, utilities, healthcare systems, and so
on) remained safely anchored to the existing mainframe-based client/server schema. Even
today, mainframes remain hard at work carrying on high-volume, real-time transactions,
such as credit card and ATM operations. Performance and cost-effectiveness are the crucial
reasons for this, despite the emergence of cloud, edge computing, Blockchain, and
massively distributed systems.

Core facts of a three-tier system

Although the skeleton of a three-tier system should be very well known to everyone in the software
space, I’ve included Figure 1-1 to illustrate it as a memento of the progressive breakup of monoliths
observed in the software industry, at least until the commercial explosion of the internet.

PRESENTATION
TIER
CLIENT
TIER
ONE BUSINESS
TIER TIER

SERVER
TIER
DATA
TIER

FIGURE 1-1 First stages of the evolution from single-tier to multi-tier architecture.

4 PART I The Holy Grail of modularity

 The advent of multi-tier systems was hailed as a vast improvement over the monolithic applications
of “prehistoric” software. Today, though—in the mid-2020s—the proposal of a multi-tier architecture is
often blissfully dismissed as obsolete and badly tagged merely as a “monolith.”

Software monoliths
The current definition of a software monolith is different from what it was in the 1990s—a start-to-
finish sequence of instructions with some input loop to keep it live and waiting for further instructions.
Today, monolithic software is commonly intended to be an application made of multiple components
combined in a single, self-contained deliverable. All the codebase lives in a single code solution and
is deployed in a single step on a single production server, whether on-premises or in the cloud. Any
constituent components become invisible from the outside once the application is deployed. Any
disastrous bug could potentially take the entire application down, and any necessary improvements
for scalability must be applied to the entire block. This can lead to significant rewrites of parts or pure
vertical hardware-based scalability.

Tier versus layer

Tiers were initially introduced to achieve physical separation between software components. In the
client/server model, the remote workstation was wired to the central server. Later, the top tier became
the presentation logic, whether made of masks, a console, or a graphical user interface (GUI). The busi-
ness tier, or application tier, was another application responsible for accessing the database server.

In the common industry jargon, the terms tier and layer are often used interchangeably. In reality,
they both refer to distinct pieces of a software application but differ significantly from a deployment
perspective. A tier denotes a physical server, or at least a different process-execution space. In contrast,
a layer is a logical container for different portions of code and needs a physical tier to be deployed.

Note All layers are deployed to a physical tier, but different layers can go to different tiers.

When it comes to production, a debatable point is whether a multi-layer application should be

mapped to a multi-tier architecture, with a one-to-one match between layers and tiers. Multiple tiers
seem to give more flexibility and ease of maintenance and scalability, but this comes at the cost of
spreading latency between tiers and subsequently making every single operation potentially slower.
In addition, deployment is more expensive in a multi-tier scenario, as more resources (on-premises or
in the cloud) are necessary.

In summary, tiers can provide a structure for scaling an application, but their mere presence doesn’t
guarantee faster performance. Efficient scaling involves not only the organization of tiers but also fac-
tors such as load balancing, code optimization, and the use of appropriate technologies for decoupling
(for example, a bus). Tiers help by offering a logical separation of responsibilities, but their performance
benefits are realized through thoughtful design, resource allocation, and performance tuning.

Chapter 1 The quest for modular software architecture 5

 The value of N
The term multi-tier (or multi-layer) refers to a number (N) of tiers (or layers) that conventionally equals
three. So, is three the ideal number of tiers (or layers)? To answer this, consider Figure 1-2.

BUSINESS #1

DATA #1

BUSINESS #2
DATA #2
PRESENTATION

DATA #M

BUSINESS #N

FIGURE 1-2 Variable number of tiers in a massively distributed application architecture.

Tiers and layers have followed different scales. The popular approach based on microservices tends
to increase the number of physical tiers up to hundreds. In contrast, the number of layers within a
single tier rarely exceeds four, which is considered the ideal number by the canonical supporting archi-
tecture of the domain-driven design (DDD) methodology. As you’ll see shortly, the four layers are:

■■ Presentation This layer collects user requests and input to submit to processing layers down
the stack.

■■ Application This layer receives raw input from the presentation layer and orchestrates any
necessary tasks.

■■ Domain This layer contains reusable domain and business logic.

■■ Infrastructure This layer deals with external services (for example, APIs and web services) and
storage.

Compared to a three-tier architecture, a multi-layered architecture is more granular, because it

splits in two an otherwise thick (and likely more convoluted) business tier.

Multi-tiered systems today

Multi-tier architecture is a well-established pattern that still serves most business scenarios today. Let’s
reflect on the flavors of multi-tier we see today in the industry.

6 Part I The Holy Grail of modularity

 One flavor is the web application. For the purposes of this book, a web application is a line-of-
business (LoB) application consumed through a client web browser application. This contrasts with
a website, in which the stratification of what is referred to as the front end is quite simple in terms of
domain complexity and workflows.

In action, a typical web application develops over two tiers: the client browser and the server (cloud)
environment, sometimes referred to as the back end. How many tiers and layers exist within the back
end? Classic ASP.NET and ASP.NET Core applications and Blazor server applications often count two
tiers and multiple (N > 3) layers. One tier is the core application, and another is represented by the
primary database server—for example, a relational database management system (RDBMS).

The challenge for everyone, then, is learning the good and bad of every possible application archi-
tecture pattern, making a thoughtful choice based on the specific business context, and, most of all,
avoiding dogmatic disputes.

Note While researching the origin of the three-tier architecture, I ran into a curious fact
I’d never heard before. In the United States during the 1930s, right after the repeal of the
Prohibition Act, the government introduced a new distributed system for ensuring people’s
access to alcohol. Guess what? It was named the three-tier system, and the tiers were, from
bottom to top, producers, distributors, and retailers.

Layers, tiers, and modularization

Modularization is the primary reason for the introduction of multiple tiers and layers. Having been
in this industry for more than 30 years now, I have observed many attempts to develop a universal
approach to componentization (or should I say, Legolization?) in software development, from Visual
Basic and Delphi components to ActiveX and COM, from JavaBeans to Web Forms server controls, and
from old-fashioned web services to microservices. Frankly, my age-dependent disillusion leads me to
state that none of them worked for more than a few people or for a limited amount of time. Still, I have
no hope and no room for universality.

Behind known benefits such as the ability to reuse components, the parallelization of development,
and ease of maintenance, the ultimate goal and primary benefit of modularization is separation of
concerns (SoC)—a universal principle of software formalized in 1974 by Edsger W. Dijkstra in the paper
“On the Role of Scientific Thought.”

Note Although I have stated the core difference between a tier and a layer, from now on,
for the sake of simplicity, I’ll use the term layer to indicate tier or layer unless it becomes
necessary to distinguish between the two.

Chapter 1 The quest for modular software architecture 7

 The presentation layer
Each of the layers briefly discussed here shares a common idea but a different implementation. In a
desktop application, for example, such as legacy Windows Forms or Windows Presentation Founda-
tion (WPF) applications, the presentation layer is the user interface. It contains a minimal amount of
presentation logic to validate input and to adjust the user interface to reflect the current state of the
application.

In contrast, in a web scenario, the user interface consists of a mixture of HTML, CSS, and JavaS-
cript rendered in a browser. Alternatively, it can be a runnable piece of WebAssembly code, like the
code generated by Blazor. Being run on a physically different machine, it is a real tier. The application,
though, might also consist of a special presentation layer whose primary purpose is to route requests
to some module to handle it. For ASP.NET Core applications, the presentation layer contains controller
classes and, more generally, code that is directly connected to reachable endpoints.

The business layer

In very abstract terms, the business layer processes information collected in the presentation layer
with other information managed by the data layer. It is also the place where business rules are known
and applied. In an ASP.NET Core scenario, the business layer is made by handlers that can respond to a
controller request and return a response for the controller to package it back to the browser.

In recent years, a commonly recurring query in training sessions and workshops pertained to
the optimal placement of specific code segments. For instance, questions often arose regarding the
appropriate location for input validation code. Should it reside in the presentation or business layer?
Alternatively, is it advisable to defer validation until it hits the database, possibly handled by a stored
procedure or some surrounding code?

At its core, the business layer leaves such gray areas unclear. For this reason, a four-layer architecture
emerged.

The data layer

This is where information processed by the application is persisted and read. The thickness of the data
layer is highly variable. It might coincide with a database server—whether relational or NoSQL—or it
could be created by code that arranges raw calls to the storage server via dedicated object-relational
mappers (ORMs) such as Entity Framework (EF) or Dapper.

Recently, the data layer has been abstracted into an infrastructural layer where persistence is just the
primary (but not unique) responsibility. Seen as infrastructure, this layer is also responsible for emails
and connections to external APIs.

8 Part I The Holy Grail of modularity

 Important The primary purpose of a multi-layered architecture is to achieve separation of
concerns (SoC) and to ensure that different families of tasks execute in a properly isolated
environment. A crucial consequence of SoC, especially when applied across multiple layers,
is that dependencies between layers must be strictly regulated. Discussing how to plan SoC
across layers in the context of a web application written for the .NET stack is the main goal of
this book.

The DDD canonical architecture

In the early 2000s, the software industry faced a gigantic challenge: modernizing, or just migrat-
ing, existing business applications to seize new opportunities presented by the breakthrough of the
internet. Attempting to adapt mainframe applications to handle the growing demand for e-commerce
introduced monumental levels of complexity.

The three-tier architecture started creaking under the weight of this complexity—not so much
because of its inherent inefficiencies, but rather due to the need to increase modularization to manage
business and implementation requirements and (hopefully) scale. (It was at this time that the term scal-
ability rose to prominence and gained its meaning as we know today—a system’s ability to maintain a
good level of service even if the number of requests grows unexpectedly.)

The domain-driven design (DDD) methodology systematized several practices and solutions that
proved valid on the ground. Bundled with the design methodology, there was also a canonical sup-
porting architecture.

Note I don’t use the phrase “monumental complexity” by chance. It is a quote from the
stories I’ve heard from the people who devised DDD and an homage to all of them.

The proposed supporting architecture

DDD proponents suggested a layered architecture to implement modules. This layered architecture
generalized the three-tier architecture obtained in three steps:

1. Tiers were generalized to layers.

2. The business layer was broken in two, with an application layer for the orchestration of use
cases and a domain layer for pure business logic. The domain layer in turn was composed of
two elements: a collection of persistence-agnostic domain models and a collection of persis-
tence-aware domain services. This is a key aspect of DDD.

3. The data layer was renamed the infrastructure layer, and the most common and important
service it provided was persistence.

Chapter 1 The quest for modular software architecture 9

 The resulting architecture—which also includes a presentation layer—is monolithic in its simplest
form but has clear boundaries at any level and well-defined flows of data exchange. In some ways, it is
even cleaner than the actual trumpeted clean architecture!

The presentation layer

The presentation layer handles interactions with external systems that send input data to the applica-
tion. This primarily includes human users, but also API calls from other running applications, notifica-
tions, bus messages, triggered events, and so on. Put another way, the presentation layer receives
requests for tasks that will be processed down the stack, producing some effect on the domain. The
presentation layer is also responsible for packaging results generated by internal layers in response to
an accepted request and for sending it back to the requestor.

The presentation layer can take various technological forms. It might be a desktop application (for
example, .NET MAUI, Electron, old-fashioned WPF, or Windows Forms), a mobile application, a mini-
mal API, or a fully-fledged web application (whether ASP.NET Core, Blazor, Angular, React, or Svelte
and friends). Also, the protocols involved may vary a bit, and include HTTPS, gRPC, and, in scenarios
involving the internet of things (IoT), Message Queue Telemetry Transport (MQTT), Advanced Message
Queuing Protocol (AMQP), and more.

Considering this, it is key to remember that despite the fact that the layer name (presentation)
evokes the presence of some graphical front end, a visual interface is not necessary. Even when the
bounded context is expected to be a plain web API, a presentation layer makes sense because, as men-
tioned, it represents a sort of reception and the gateway to internal functions and layers.

The application layer

Whereas the presentation layer collects requests, the application layer coordinates any subsequent
processing. The application layer, in fact, is where business workflows are launched and monitored. Any
single request managed at the upper level finds a concrete executor in the application layer. A term
that well describes the behavior of the application layer is orchestrator. A more elaborate job descrip-
tion is that the application layer is responsible for the implementation of the various use cases.

Important In a classic three-tier scenario, the well-defined responsibilities described here

are shared between all the tiers—presentation, business, and data—in percentages that
vary between implementations based on the view and sensitivity of the involved teams.

The application layer goes hand-in-hand with the presentation layer and supplies one action
method for each possible trigger detected by the presentation actors. When multiple versions of an
application are necessary (say, one for web and one for mobile), each should have its own application
layer unless the triggers and expected reactions are nearly the same.

10 Part I The Holy Grail of modularity

Random documents with unrelated
content Scribd suggests to you:
et Germanicis, si bene memini.” Mr. Douce cites this
passage from Gesner’s Pandectæ, “a supplemental volume
of great rarity to his well-known Bibliotheca.” The correct
title of the volume in which it occurs is “Partitiones
Theologicæ, Pandectarum Universalium Conradi Gesneri
Liber Ultimus.” Folio, printed by Christopher Froschover,
Zurich (Tiguri) 1549. The notice of the Dance of Death is in
folio 86, a.
VI.42 Traité de la Gravure en Bois, tom. i. p. 165. Van
Mander asserts that Holbein painted with his left hand; but
Horace Walpole, however, in opposition to this, refers to a
portrait of Holbein, formerly in the Arundelian collection,
where he appears holding the pencil in his right hand.
VI.43 A copy of this edition is preserved in the Public
Library at Basle, and there is another copy in the Royal
Collection at Dresden. Another edition, in every respect
similar to the first, was also printed by the brothers
Trechsel in 1539. Hegner, in his Life of Holbein, does not
seem to have known of this edition; speaking of that of
1538, he says, “It is probably the same as that to which
Papillon gives the date 1539.” There is a copy of the edition
of 1539 in the British Museum.
VI.44 “A comparison of the 8th subject of the Simulachres,”
says Mr. Douce, “with that of the Bible for Esther i, ii,
where the canopy ornamented with fleurs-de-lis is the same
in both, will contribute to strengthen the above conjecture,
as will both the cuts to demonstrate their Gallic origin. It is
most certain that the King sitting at table in the
Simulachres is intended for Francis I, which if any one
should doubt, let him look upon the miniature of that king,
copied at p. 214, in Clarke’s ‘Repertorium Bibliographicum.’”
The “above conjecture” referred to in this extract is that
previously cited at page 367, where Mr. Douce conjectures
that Holbein might have been employed to complete the
Bible cuts which might have been left unfinished in
consequence of the death of Mr. Douce’s “great unknown”
designer of the Dance of Death.—Dance of Death, p. 96.
Mr. Douce, not being able to deny the similarity of many of
the cuts, says it is highly probable that Holbein was merely
employed to finish the Bible cuts, without ever considering
that it is primâ facie much more probable that Holbein was
the designer of the cuts in both works.
VI.45 Dance of Death, p. 82.
VI.46 “Venit nuper Basileam ex Anglia Ioannes Holbein,
adeo felicem ejus regni statum prædicans, qui aliquot
septimanis exactis rursum eo migraturus est.” From a letter
written by Rudolph Gualter to Henry Bullinger, of Zurich,
about the middle of September 1538.—Quoted by Hegner,
S. 246.
VI.47 Dr. Dibdin, in his Bibliographical Tour vol. iii. pp. 80,
81, Edit. 1829, mentions two paintings at Augsburg by the
elder Holbein, one dated 1499 and the other 1501. The
elder Holbein had a brother named Sigismund, who was
also a painter, and who appears to have established himself
at Berne. Papillon, in his usual manner, makes Sigismund
Holbein a wood engraver. By his will, dated 1540, he
appoints his nephew Hans the heir of all his property in
Berne.
VI.48 Patin’s edition of this work was published in octavo,
at Basle, in 1676. It contains eighty-three copper-plate
engravings, from pen-and-ink sketches, drawn by Holbein,
in the margin of a copy of an edition printed by Frobenius,
in 1514, and still preserved (1860) in the Public Library at
Basle. It is said that Erasmus, when looking over those
sketches, exclaimed, when he came to that intended for
himself, “Oho, if Erasmus were now as he appears here, he
would certainly take a wife.” Above another of the sketches,
representing a man with one of his arms about a woman’s
neck, and at the same time drinking out of a bottle,
Erasmus is said to have written the name “Holbein.” In an
edition of the Laus Stultitiæ, edited by G. G. Becker, Basle,
1780, 8vo. those sketches are engraved (very indifferently)
on wood.
VI.49 Hegner, Hans Holbein der Jüngere, S. 110.
VI.50 It is conjectured by Walpole that this might be Henry
Fitz-Alan, Earl of Arundel.
VI.51 It is impossible to exceed the beauty and skill that
are manifested in this fine piece of art. The figures are,
a king, queen, and a warrior; a young woman, a monk, and
an infant; all of whom most unwillingly accompany Death in
the Dance. The despair of the king, the dejection of the
queen, accompanied by her little dog, the terror of the
soldier who hears the drum of Death, the struggling of the
female, the reluctance of the monk, and the sorrow of the
poor infant, are depicted with equal spirit and veracity. The
original drawing is in the public library at Basle, and
ascribed to Holbein.
VI.52 The verses underneath the impressions which are
supposed to be the earliest, are as follows:
“Corporis effigiem si quis non vidit Erasmi,
Hunc scite ad vivum picta tabella dabit.”
The others:
“Pallas Apellæam nuper mirata tabellam,
Hanc, ait, æternum Bibliotheca colat.
Dædaleam monstrat musis Holbeinnius artem,
Et summi ingenii Magnus Erasmus opes.”
VI.53 Erasmus, writing to Bilibald Pirkheimer, in 1524, says,
“Rursus nuper misi in Angliam Erasmum bis pictum ab
artifice satis eleganti.” Hegner thinks that this artist was
Holbein. In 1517 a portrait of Erasmus, with that of his
friend Petrus Aegidius, was painted at Antwerp by Quintin
Matsys. It was intended by Erasmus as a present to Sir
Thomas More. This painting came subsequently into the
possession of Dr. Mead, at whose sale it was purchased, as
the production of Holbein, by Lord Radnor, for £110.
VI.54 “Pictor tuus, Erasme carissime, mirus est artifex, sed
vereor ne non sensurus sit Angliam tam fœcundam ac
fertilem quam sperarat. Quanquam ne reperiat omnino
sterilem, quoad per me fieri potest, efficiam. Ex aula
Grenwici. 18 Dec. 1525.”
VI.55 “Qui has reddit, est is qui me pinxit. Ejus
commendatione te non gravabo, quanquam est insignis
artifex. Si cupiet visere Quintinum, nec tibi vacabit
hominem adducere, poteris per famulum commonstrare
domum. Hic frigent artes: petit Angliam ut corradat aliquot
angelatos: per eum poteris quæ voles scribere.”—Erasmi
Epist.
VI.56 Erasmus, in a letter to Sir Thomas More, written from
Freyburg in Brisgau, 5th September, 1529, alludes to a
picture of More and his family which had been brought over
by Holbein; and Margaret Roper, the eldest daughter of Sir
Thomas More, writing to Erasmus in the following
November, says, that she is pleased to hear of the painter’s
arrival with the family picture,—“utriusque mei parentis
nostrumque omnium effigiem depictam.” Hegner thinks that
those portraits of Sir Thomas More and his family was only
a drawing in pen-and-ink, which is now in the Public Library
at Basle. The figures in this drawing are: Sir Thomas and
his wife, his father, his son, and a young lady, three
daughters, a servant, and Sir Thomas’s jester. Over and
under the figures are written the name and age of each.
The drawing is free and light; and the faces and hands are
very distinctly expressed.—Hans Holbein der Jüngere,
S. 202-235-237. The drawing in the Public Library at Basle
was probably a sketch of Holbein’s large picture of the
family of Sir Thomas More.
VI.57 Holbein’s wife and child only, not children, are
mentioned in this licence. It is not known what became of
Holbein’s children, as there are no traces of his descendants
to be found at Basle. Merian, a clergyman of Basle, in a
letter to Mechel on this subject, in 1779, writes to this
effect: “According to a pedigree of the Merian family,
printed at Regensburg in 1727, Christina Syf, daughter of
Rodolph Syf and Judith Weissin, and grand-daughter of
Hans Holbein the unequalled painter, (born 1597,) was
married on the 17th of November 1616 to Frederick
Merian.” Perhaps it is meant that Judith Weissin was
Holbein’s grand-daughter: there is evidently an error in the
pedigree; and if it be wrong in this respect, it is not entitled
to much credit in another.
VI.58 Hegner, S. 242.
VI.59 See Dallaway’s edition, revised by R. N. Wornum.
London, Bohn, 1849, 3 vols. 8vo. Vol. i. pp. 66 et seq.
VI.60 Those designs were engraved on sixteen small plates
by Hollar, but without his name. The enemies of Christ are
represented in the dress of monks and friars, and instead of
weapons they bear croziers, large candlesticks, and other
church ornaments; Judas appears as a capucin, Annas as a
cardinal, and Caiaphas as a bishop. In the subject of
Christ’s Descent to Hades, the gates are hung with papal
bulls and dispensations; above them are the Pope’s arms,
and the devil as keeper of the gate wears a triple crown.
Underneath this engraving are the following verses, which
are certainly not of the period of Holbein:
“Lo! the Pope’s kitchin, where his soles are fried,
Called Purgatorie; see his pardons tied
On strings; his triple crown the Divell weares,
And o’er the door the Pope’s own arms he beares.”
In the subject of Christ before Caiaphas is the following
inscription in German: “Wer wider die Römischen, der soll
sterben,”—that is, “He who is against the Romans shall die.”
VI.61 The following is the title of this scarce little volume.
“Catechismus, that is to say, a shorte instruction into
Christian religion for the singuler commoditie and profyte of
childrē and yong people. Set forth by the mooste reverende
father in God, Thomas Archbyshop of Canterbury, primate
of all Englande and Metropolitane.—Gualterus Lynne
excudebat, 1548.” At the end of the book, under a cut of
Christ with a child before him, is the colophon: “Imprynted
at London, in S. Jhones Streete, by Nycolas Hyll, for
Gwalter Lynne dwellyng on Somers kaye, by Byllynges
gate.” Mr. Douce, at page 96, mentions a cut with the name
Hans Holbein at the bottom, as occurring in the title-page
of “A lytle treatise after the manner of an Epystle wryten by
the famous clerk Doctor Urbanus Regius,” &c. also
published by Walter Lynne, 1548.
VI.62 Mr. Douce, in his observations prefixed to Hollar’s
etchings of the Dance of Death, published by Edwards in
1794, says, “A set of cuts with the latter mark [Hans
Holben] occurs in Archbishop Cranmer’s Catechism, printed
by Walter Lyne, in 1548;” and in the same page he commits
another mistake by describing the mark on the cut of the
Duchess in the Lyons Dance of Death as , instead of
. It has been considered necessary to notice these errors,
as it is probable that many persons who possess the work
in which they occur, but who never may have seen a copy
of the Lyons Dance of Death, nor of Cranmer’s Catechism,
may have been misled in those matters by implicitly relying
on Mr. Douce’s authority. A certain class of compilers are
also extremely liable to transmit such mistakes, and, to
borrow an expression of Hegner’s, to give currency to
them, as if they stood ready for use “in stereotype.”
VI.63 The title-page of this book—which has previously
been referred to at page 357, in illustration of the word
picta—is as follows: “Novi Testamenti Editio postrema per
Des. Erasmum Roterodamum. Omnia picturis illustrata.
Accesserunt Capitum argumenta Elegiaco carmine,
Rudolpho Gualtero authore, conscripta. Tiguri, in Officina
Froschoviana. Anno m.d.liiii.” 8vo.
VI.64 The volume is of octavo size, and the title is as
follows: “The Newe Testament. Imprinted at Antwerp by
Marten Emperour. Anno m.d.xxxiiii.” The letters on the
wood-cut of the printer’s device, seen in the copies on
paper, are m. k. The first edition of Tindale’s Translation was
printed in 1526. William Tindale, otherwise Hitchins, was
born on the borders of Wales, but was of a Northumberland
family, being descended from Adam de Tindale of Langley,
near Haydon Bridge, in that county. He was strangled, and
his body was afterwards burnt as that of a heretic by the
popish party, at Vilvorde, near Brussels, in 1536.
VI.65 The title of this edition is as follows: “Biblia. The
Bible, that is, the holy Scripture of the Olde and Newe
Testaments, faithfully translated out of Douche and Latyn in
to Englishe. m.d.xxxv.” This title is surrounded with an
ornamental wood-cut border of ten compartments: 1. Adam
and Eve. 2. The name of Jehovah in Hebrew characters in
the centre at the top. 3. Christ with the banner of the cross
trampling on the serpent, sin, and death. 4. Moses
receiving the tables of the law. 5. Jewish High Priest,—
Esdras. 6. Christ sending his disciples to preach the Gospel.
7. Paul preaching. 8. David playing on the harp. 9. In the
centre at the bottom, King Henry VIII. on his throne giving
a book—probably intended for the Bible—to certain abbots
and bishops. 10. St. Paul with a sword. The day of the
month mentioned in the colophon was probably the date of
the last sheet being sent to press: “Prynted in the yeare of
our Lorde m.d.xxxv, and fynished the fourth daye of
October.” Copies of this edition with the title-page are
extremely rare. Some copies have a modern lithographed
title prefixed, which is not exactly correct, though
professedly a fac-simile: in one of the scrolls it has “telius
meus” for “filius meus.” In the corresponding scroll in a
copy in the British Museum the words are in English: “This
is my deare Son in whom I delyte, heare him,”—above the
figure of Christ with the banner of the cross. I have not the
least doubt of this title-page having been designed by
Holbein.
VI.66 The following is the title of this curious and scarce
work: “Le Sorti di Francesco Marcolini da Forli, intitolate
Giardino di Pensieri.” Dedicated, “Allo Illustrissimo Signore
Hercole Estense, Duca di Ferrara.” At the conclusion is the
colophon: “In Venetia per Francesco Marcolini da Forli, ne
gli anni del Signore mdxxxx. Del mese di Ottobre.” In a
proemio, or preface, the author explains the manner of
applying his “piacevole inventione,” which is nothing more
than a mode of resolving questions by cards, and was
probably suggested by Fanti’s Triompho di Fortuna, of
which some account is given at page 315.
VI.67 Papillon, Traité de la Gravure en Bois, tom. i. p. 137.
VI.68 This catalogue is printed in the second volume of
Heineken’s Nachrichten von Künstlern und Kunst-Sachen,
8vo. Leipzig, 1768-1769. This work, which appeared two
years before his Idée Générale d’une Collection complette
d’Estampes, contains much information on the early history
of art, which is not to be found in the latter. All the fac-
similes of old engravings in the Idée Générale originally
appeared in the Nachrichten. Heineken, in the first volume
of this work, p. 340, mentions Porta’s cut, but says nothing
of its being copied from a design by Raffaele.
VI.69 Heineken, in his Nachrichten, 1er. Theil, S. 340, says
that Joseph Porta “was a pupil of Cecchino Salviati, who is
not to be confounded with Francesco Salviati;” and yet in
his Idée Générale, published subsequently, page 134, we
find “Francesco del Salviati, autrement Rossi, de Florence,
et son disciple Giuseppe Porta, appellé communément
Giuseppe Salviati.” Heineken, in his first work, committed
the mistake of supposing that Francesco Salviati’s to-name
was the Christian name of another person. In Huber’s
Notice Générale des Graveurs et Peintres, Francis Salviati
appears as “François Cecchini, dit Salviati.”
VI.70 The first forty-six cuts are the best, generally, both in
design and execution. The others, commencing at page
108, are illustrative of the sayings and doctrines of ancient
philosophers and moralists, and one or two of the cuts are
repeated. In this portion of the work, each page, except
what is occupied by the cut, is filled with explanatory or
illustrative verses arranged in triplets.
VI.71 The first hundred and seven pages of the work are
chiefly filled with similar figures of cards variously
combined, with short references. How Marcolini’s pleasant
invention is to be applied to discover the secrets of Fate,
I have not been able to comprehend.
VI.72 The following is a literal copy of the title: “Libro di
M. Giovam Battista Palatino, Cittadino Romano, Nelqual
s’insegna à Scriver ogni sorte lettera, Antica & Moderna, di
qualunque natione, con le sue regole, & misure, & essempi:
Et con un breve, et util Discorso de le Cifre: Riveduto
novamente, & corretto dal proprio Autore. Con la giunta di
quindici tavole bellissime.” At the end of the work is the
imprint: “In Roma per Valerio Dorico alla Chiavica de Santa
Lucia. Ad Instantia de M. Giovan della Gatta. L’Anno m.d.lxi.”
4to. Papillon says that the work first appeared in 1540, and
was reprinted in 1545, 1547, 1548, 1550, 1553, and 1556.
An edition was also published at Venice in 1588.
VI.73 There is a curious allusion to a Rebus in Horace,
Satyr. Lib. I. Sat. V., Vers. 88, which has escaped the notice
of all his commentators:
“Quatuor hinc rapimur viginti et millia rhedis,
Mansuri oppidulo, quod versu dicere non est,
Signis perfacile est.”
The place which he did not think proper to name was
undoubtedly Asculum, whose situation exactly corresponds
with the distance from Trivicum, where he rested the
preceding night. From the manner in which Horace alludes
to the signa—as and culum—of which the name is
composed, it seems likely that a certain vulgar benison was
not unknown at Rome in the age of Augustus.
VI.74 Remaines concerning Britaine, with additions by John
Philpot, Somerset Herald, p. 164. Edit. 1636.
VI.75 Papillon, who speaks highly of the execution of the
cuts ascribed to Bernard Solomon, admits that they want
effect. “La gravure,” says he, speaking of the cuts contained
in ‘Quadrins Historiques de la Bible,’ “est fort belle, excepté
qu’elle manque de clair obscur, parce que les tailles sont
presque toutes de la même teinte, ce qui fait que les
lointains ne fuyent pas assez. C’est le seul defaut des
gravures de Bernard Salomon; ce qui lui a été commun
avec plus de quarante autres graveurs en bois de son
temps.”—Traité de la Gravure en Bois, tom. i. p. 209.
VI.76 Several editions of Alciat’s Emblems and Claude
Paradin’s Devises Heroïques were published at Lyons in the
sixteenth century. The first edition of the latter work was
printed there by Jean de Tournes, in 1557, 8vo.
VI.77 The following explanatory title occurs on the first cut:
“Ces moeurs et fachons de faire de Turcz avecq’ les Regions
y appartenantes, ont este au vif contrefactez par Pierre
Coeck d’Alost, luy estant en Turquie, l’an de Jesu Christ m.d.
33. Lequel assy de sa main propre a pourtraict ces figures
duysantes à l’impression d’ycelles.” From another of the
cuts we thus learn the time of his death: “Marie Verhulst
vefue du dict Pierre d’Alost, trespasse en l’anne mdl, a faict
imprimer les dicts figures soubz Grace et Privilege de
l’Imperialle Maiestie. En l’Ann mcccccliii.”
VI.78 This interesting specimen of the combined arts of
wood engraving and printing formerly belonged to the late
Mr. Robert Branston, wood engraver, who executed several
of the chiaro-scuros, and imitations of coloured drawings, in
Savage’s work on Decorative Printing. It is now in the
possession of his son, Mr. Frederick Branston, who is of the
same profession as his father.
VI.79 The title-page of this work is printed in three colours,
—black, sepia, and green. The black ornamental outlines
are from an etched plate; the sepia and green colours are
printed from wood-blocks. An edition of this work, enlarged
by Gevartius, with portraits in two colours, and entirely
engraved on wood, was printed at Antwerp in 1645.
VI.80 Tom. i. p. 129. Paris, 1753.
VI.81 The following is a copy of the title: “Underweisung
der Proportzion und Stellung der Possen, liegent und
stehent; abgestochen wie man das vor augen sieht, in dem
puchlein, durch Erhart Schon von Norrenberg; für die
Jungen gesellen und Jungen zu unterrichtung die zu der
Kunst lieb tragen. In den druck gepracht, 1538.”
VI.82 This last letter contains the mark , which is to be
found on some of the cuts in the editions of the Dance of
Death printed at Cologne, 1555-1572.
VI.83 The title is as follows: “Johan. Posthii Germershemii
Tetrasticha in Ovidii Metam. Lib. xv. Quibus accesserunt
Vergilii Solis figuræ elegantissimæ, primum in lucem editæ.
—Schöne Figuren, auss dem fürtrefflichen Poeten Ovidio,
allen Malern, Goldtschmiden, und Bildthauern, zu nutz und
gutem mit fleiss gerissen durch Vergilium Solis, und mit
Teutschen Reimen kürtzlich erkläret, dergleichein vormals
im Druck nie aussgangen, Durch Johan. Posthium von
Germerssheim. m.d.lxix.”
VI.84 Hans Sachs, whose poetical works might vie in
quantity with those of Lope Vega, was born at Nuremberg
in 1494. Notwithstanding the immense number of verses
which he composed, he did not trust to his profession of
Meistersänger for the means of living, but continued to
carry on his business as a shoemaker till his death, which
happened in 1576. His verses were much admired by his
contemporaries; and between 1570 and 1579, a collection
of his works was published in five volumes folio. Several
short pieces by him were originally printed as “broadsides,”
with an ornamental or illustrative cut at the top.
VI.85 Papillon, who appears to have been extremely wishful
to swell his catalogue of wood engravers, describes Jost
Amman of Zurich and Jost Amman of Nuremberg as two
different persons.
VI.86 Heineken, Idée Générale, p. 244.
VI.87 The following is the title of the edition of 1568;—that
of 1574 is somewhat different. “πανοπλια omnium
Illiberalium mechanicarum aut sedentariarum artium,
continens quotquot unquam vel a veteribus, aut nostri
etiam seculi celebritate excogitari potuerunt, breviter et
dilucide confecta: carminum liber primus, tum mira
varietate rerum vocabulorumque novo more excogitatorum
copia perquam utilis, lectuque jucundus. Accesserunt etiam
venustissimæ Imagines omnes omnium artificum
negociantes ad vivum lectori representantes, antehac nec
visæ nec unquam æditæ: per Hartman Schopperum,
Novoforens. Noricum.—Frankofurti ad Moenum, cum
privelegio Cæsario, m.d.lxviii.”
VI.88 The Briefmalers, though at that time evidently distinct
from the Formschneiders, still continued to print wood-cuts.
On several large wood-cuts with the dates 1553 and 1554
we find the words, “Gedrukt zu Nürnberg durch Hanns
Glaser, Brieffmaler.”
VI.89 See the mark C. S. at page 413.
VI.90 This work is entitled “Kunstbüchlein,” and consists
entirely of cuts without any explanatory letter-press. The
first cut consists of a group of heads, drawn and engraved
with great spirit. On what appears something like a slab of
stone or wood—most unmeaningly and awkwardly
introduced—are Jost Amman’s initials, I.A., towards the top,
and lower down the mark, which is doubtless that of
the engraver. This mark, with a figure of a graver
underneath, occurs on several of the other cuts. The three
following marks, with a graver underneath each, also occur:
L. F. C.S. G. H. These facts are sufficient to prove that Jost
Amman was not the engraver of the cuts which he
designed. In the edition of 1599 the cuts are said to have
been drawn by “the late most excellent and celebrated
artist, Jost Amman of Nuremberg.”
VI.91 It is uncertain if James I. or James II. be meant.
According to Sir Walter Scott, Aeneas Sylvius, afterwards
Pope Pius II, visited Scotland in 1448, when James II.—if
Chalmers be correct, Caledonia, vol. i. p. 831,—was
scarcely nineteen, and when his appearance was not likely
to correspond with the learned prelate’s description,
—“hominem quadratum et multa pinguedine gravem.”
VI.92 “Avium præcipuarum, quarum apud Plinium et
Aristotelem mentio est, brevis et succincta historia. Per Dn.
Gulielmum Turnerum, artium et medicinæ doctorem,” 8vo.
Coloniæ, m.d.xliiii, fol. 9 b.
VI.93 In Professor Christ’s Dictionary of Monograms this
mark is ascribed, though doubtfully, to “Manuel Deutsch.” It
is certainly not the mark of Nicholas Emanuel Deutsch of
Bern, for he died several years before 1548, the date on
several of the cuts with the mark H.R. M.D. in Munster’s
Cosmography, and which date evidently relates to the year
in which the artist made the drawing. There can be no
doubt that those four letters belong to a single name, for
some of the cuts in which they occur also contain the mark
of an engraver.
VI.94 A map of Russia, engraved wholly on wood, in a work
entitled “Commentari della Moscovia e parimente della
Russia,” &c. translated from the Latin of Sigmund, Baron
von Herberstein, printed at Venice, 4to. 1550, is much
superior in point of appearance to the best in the work of
Munster. This map, which is of folio size, appears to have
been constructed by “Giacomo Gastaldo, Piamontese,
Cosmographo in Venetia.” The work also contains six wood-
cuts, which afford some curious specimens of Russian and
Tartar arms and costume.
VI.95 Philologicarum Epistolarum Centuria una, ex
Bibliotheca M. H. Goldasti, p. 165. 8vo. Francofurti, 1610.
VI.96 According to this method, certain words, together
with radices and terminations of frequent occurrence, were
cast entire, and not in separate letters, and placed in cases
in such an order that the compositor could as “readily
possess himself of the Type of a word as of the Type of a
single letter.” This method, for which a patent was
obtained, is explained in a pamphlet entitled “An
Introduction to Logography: or the Art of Arranging and
Composing for Printing with Words entire, their Radices and
Terminations, instead of single Letters. By Henry Johnson:
London, printed Logographically, and sold by J. Walter,
bookseller, Charing Cross, and J. Sewell, Cornhill,
m.dcc.lxxxiii.”
Several works were printed in this manner,
and among others an edition of Anderson’s History of
Commerce, 4 vols. 4to. 1787-1789, by John Walter, at the
Logographic Press, Printing-House-Square, Blackfriars.
Logography has long been abandoned. The following
account of this art is given in H. G. Bohn’s Lecture on
Printing, pp. 88, 89. “Something akin to stereotyping is
another mode of printing called Logography, invented by
the late Mr. Walter, of the Times, in 1783, and for which he
took out a patent. This means a system of printing from
type cast in words instead of single letters, which it was
thought would save time and corrections when applied to
newspapers, but it was not found to answer. A joke of the
time was a supposed order to the typefounder for some
words of frequent occurrence, which ran thus:—‘Please
send me a hundred-weight, sorted, of murder, fire, dreadful
robbery, atrocious outrage, fearful calamity, alarming
explosion, melancholy accident; an assortment of
honourable member, whig, tory, hot, cold, wet, dry; half-a-
hundred weight, made up in pounds, of butter, cheese,
beef, mutton, tripe, mustard, soap, rain, &c.; and a few
devils, angels, women, groans, hisses, &c.’ This method of
printing did not succeed: for if twenty-four letters will give
six hundred sextillions of combinations, no printing office
could keep a sufficient assortment of even popular words.”
VI.97 See an edition of Ptolemy, printed at Venice by
Jacobus Pentius de Leucho, in 1511, previously noticed at
page 203.
VI.98 Some account of this work is given at page 200.
VI.99 At page 204 it is stated, on the authority of Breitkopf,
that those maps were engraved by Ægidius Diest. Ortelius
himself says in the preface that they were engraved by
“Francis Hogenberg, Ferdinand and Ambrose Arsens, and
others.”
VI.100 The portrait of Queen Elizabeth appears on the title;
the Earl of Leicester’s is prefixed to the Book of Joshua; and
Lord Burleigh’s is given, with a large initial B, at the
beginning of the first psalm. In the second edition, 1572,
the portrait of Lord Burleigh is omitted, and the impressions
of the other two are much inferior to those in the first
edition in consequence of the plates being worn. Many of
the cuts in the second edition are quite different from those
in the first, and generally inferior to the cuts for which they
are substituted.
VI.101 “Humphrey Cole, as he says himself, was born in the
North of England, and pertayned to the mint in the Tower,
1572. I suppose he was one of the engravers that
pertayned to Archbishop Parker, for this edition was called
Matthew Parker’s Bible. I hope the flattery of the favourites
was the incense of the engraver!” Catalogue of Engravers,
p. 16. Edit. 1794.—Walpole does not appear to have paid
the least attention to the engraver’s merits—supposing, as
he does, the portraits to have been executed by him:—he
sneers at him because he had engraved certain portraits for
a Bible, and because he was supposed to have been
patronised by a bishop. A more liberal writer on art would
have praised Parker, although he were an archbishop, for
his patronage of a native engraver.
VI.102 “Augustinus Ryther, Anglus,” occurs on the maps of
Cumberland and Westmorland, Gloucester, and Yorkshire.
Ryther afterwards kept a bookseller’s shop in Leadenhall-
street. He engraved some maps and charts, which were
published about 1588. On the map of the county of
Hertford, Reynolds’s name occurs thus: “Nicholas
Reynoldus, Londinensis, sculpsit.” Several of those maps
were engraved by Remigius Hogenberg, one of the
engravers who are said to have been employed by
Archbishop Parker in his palace at Lambeth.
VI.103 This little work, entitled “Commentarioli Britannicæ
Descriptionis Fragmentum,” was sent by the author to
Ortelius, and the prefatory address is dated Denbigh, in
North Wales, 30th August 1568. A translation of it, under
the title of a “Breviary of Britain,” was printed at London in
1573.—Lhuyd had only furnished Ortelius with materials for
the construction of the map of England.
VI.104 The name of “Thomas Raynalde, Physition,” is not to
be found in the edition of 1540. The title of the work is,
“The byrth of Mankynd, newly translated out of Latin into
Englysshe. In the which is entreated of all suche thynges
the which chaunce to women in theyr labor,” &c. At folio vi.
there is an address from Richard Jonas, “Unto the most
gracious, and in all goodnesse most excellent vertuous Lady
Quene Katheryne, wyfe and most derely belovyd spouse
unto the moste myghty sapient Christen prynce, Kynge
Henry the VIII.”—This “most excellent vertuous lady” was
Catherine Howard. The imprint at the end of the work is as
follows: “Imprynted at London, by T. R, Anno Domini,
m.ccccc.xl.” Raynalde’s name first appears in the second
edition, 1545. Between 1540 and 1600 there were at least
eight editions of this work printed in London.
VI.105 At the end of the dedication to Henry VIII. he signs
himself “Thomas Geminus, Lysiensis.”
VI.106 In the edition of 1559 there is a large wood-cut
—“Interiorum corporis humani partium viva delineatio”—
with the mark R. S. and a graver underneath. In this cut
the interior parts of the body are impressed on separate
slips, which are pasted, by one edge, at the side of the
figure. Those slips on being raised show the different parts
as they occur on dissection.
VI.107 In Herbert’s edition of the Typographical Antiquities,
vol. iii. p. 1681, both parts of this work are said to have
engraved titles, and the arms of Sir C. Hatton are said to
occur at the back of the title to the first part. The work
contains twenty-two maps and charts, probably copied from
the original Dutch edition of Wagenar, who was a native of
Enchuysen. There is no printer’s name in the English
edition.
VI.108 Walpole erroneously states that “Broughton’s book
was not printed till 1600,” and he says that “the cuts were
probably engraved by an English artist named William
Rogers.” The mark is to be found on some of the plates
of the edition of 1600, but it is to be observed that they are
not the same as those in the edition of 1591. The first
edition of the work was printed in 1588.
VI.109 The following is the title of this work: “The
Cosmographical Glasse, conteinyng the pleasant Principles
of Cosmographie, Geographie, Hydrographie or Navigation.
Compiled by William Cuningham, Doctor in Physicke.
Excussum Londini in officina Joan. Daii, Anno 1559.
In this Glasse, if you will beholde
The starry skie and yearth so wide,
The seas also, with the windes so colde,
Yea, and thy selfe all these to guide:
What this Type mean first learne a right,
So shall the gayne thy travaill quight.”
The “Type” mentioned in these verses relates to the various
allegorical and other figures in the engraved title-page.
VI.110 This mark, which occurs in two other cuts of large
letters in the Cosmographical Glasse, is also to be found on
a large ornamented letter in Robert Record’s Castle of
Knowledge, folio, printed at London, by Reginald Wolfe,
1556. This work, like that of Cuningham, is a treatise on
Geography. A mark, I. C., with a graver between the letters,
occurs frequently in cuts which ornament the margins of a
work entitled “A Book of Christian Prayers,” &c. 4to. first
printed by John Day in 1569. It is usually called “Queen
Elizabeth’s Prayer Book.” In Herbert’s edition of the
Typographical Antiquities it is erroneously stated that such
of the cuts as relate to the History of Christ are “after
Albert Durer and his wife, Agnes Frey.” They are not copied
from any cuts designed by Albert Durer, and his wife most
certainly neither drew nor engraved on wood. It is also
incorrectly stated “that a Dance of Death, in the same
work, is after Hans Holbein.”—The cuts in this work are very
unequal in point of execution. The best are those of the
Senses—without any mark—Sight, Hearing, Taste, Smelling,
and Touch. A mark not unlike that in the letter A, from
Cuningham’s Cosmographical Glass, occurs on several of
the smaller cuts.
VI.111 This work contains a considerable number of wood-
cuts, all undoubtedly designed and engraved in England.
Two of the best are Henry VIII, attended by his council,
giving his sanction to the publication of the Bible in English,
with the mark I. F.; and a view of Windsor Castle, with the
mark M. D. Both these cuts are in the second volume of the
edition of 1576.
VI.112 Dr. Dibdin, in his Preliminary Disquisition on Early
Engraving and Ornamental Printing, in his edition of Ames
and Herbert’s Typographical Antiquities, has given several
curious specimens of large ornamented capitals.
VI.113 Bibliographical Decameron, vol. i. p. 289.
VI.114 “The pavement of this cathedral is the work of a
succession of artists from Duccio down to Meccarino, who
have produced the effect of the richest mosaic, merely by
inserting grey marble into white, and hatching both with
black mastic. The grandest composition is the History of
Abraham, a figure which is unfortunately multiplied in the
same compartments; but, when grasping the knife, the
patriarch is truly sublime. These works lay exposed at least
for a hundred years to the general tread, and have been
rather improved than defaced by the attrition; for one
female figure which had never been trodden looks harsher
than the rest. Those of the choir were opportunely covered
two centuries ago.”—Forsyth’s Italy, p. 102, 2nd Edit.
VI.115 The following is the title of this work, which is a
large octavo: “De gli Habiti Antichi et Moderni di diverse
Parti del Mondo Libri due, fatti da Caesare Vecellio, & con
Discorsi da lui dichiriati. In Venetia, md.xc.” This work is thus
mentioned in the notes to Rogers’s Italy: “Among the Habiti
Antichi, in that admirable book of wood-cuts ascribed to
Titian, (A. D. 1590,) there is one entitled Sposa Venetiana à
Castello. It was taken from an old painting in the Scuola di
S. Giovanni Evangelista, and by the writer is believed to
represent one of the brides here described.”—Italy, p. 257,
note. Edit. 1830.
VI.116 A dog performing the same act occurs as a tail-piece
in the first edition of Bewick’s Quadrupeds, 1790, page 310.
VI.117 I have seen a large head, which at first sight might
be mistaken for an impression from a wood-block, executed
by means of a stencil after a design of Correggio. It was
unquestionably old, and was about three feet high by two
and a half wide.
VI.118 The following is Papillon’s description of this cut:
“Une Estampe que je possede, et que l’on regarde assez
indifférement, est le Laocoon gravé en bois par le Titien,
représenté sous la figure d’un singe et ses deux petits
entourés de serpens. Il fit ce morceau pour railler les
Peintres de son temps qui étudoient cette figure et les
Statues antiques; et il prétendit démontrer par cette
Estampe qu’ils ressembloient aux singes, lesquels ne font
qu’imiter ce qu’ils voyent, sans rien inventer d’eux
mêmes.”—Traité de la Gravure en Bois, tom. i. p. 160.
VI.119 There is also in the Print Room of the British
Museum a curious wood-cut, of large size, engraved on
several blocks, apparently of the time of James I. The title
at the top, in Latin and English, is as follows: “Humanæ vitæ
imago olim ab Apelle in tabula quadam depicta. The image of the
lyfe of man that was painted in a table by Apelles.” The
subject, however, is not so much a general representation
of the life of man in its several stages, as an allegorical
representation of the evils attendant on sensual indulgence.
Several of the figures are designed with great spirit, and
the explanations underneath the principal are engraved on
the same block, in Latin and English. It seems likely that
this cut was engraved for the purpose of being pasted or
hung against a wall. It is about five feet four inches wide by
about three feet high. Some of the figures are engraved
with considerable spirit, but the groups want that well-
contrasted light and shade which give such effect to the
large cuts of Durer and Burgmair. It is likely that large cuts
of this kind were intended to be pasted on the walls of
rooms, to serve at once for instruction and ornament, like
“King Charles’s Golden Rules and the Royal Game of Goose”
in later times.—To this note Mr. Jackson adds in his
annotated copy: “The drawing appears to have been
executed by an artist who was rather partial to cross-
hatching, and the engraving by one who knew how to
render every line before him with a degree of sharpness
and delicacy by no means common at that period.”
VI.120 The original cut is twenty-three inches and a half
wide by eighteen inches high.
VI.121 The original is eighteen inches wide by thirteen
inches and a half high, including the margin with the
inscription “Cum privilegiis,” which is engraved on the same
block.
VI.122 Papillon, tom. i. p. 274-276, calls this engraver C. S.
Vichem; and charges Professor Christ with confounding
three Sichems with three Vichems. The name at the bottom
of the cut, in the following page, is most certainly intended
for C. V. Sichem.
VI.123 The twelfth volume of Bartsch’s Peintre-Graveur
contains an ample list of Italian chiaro-scuros, together with
the names of the painters and engravers.
VI.124 The only perfect copy which I have seen of this little
work is in Spanish. The title is as follows: “La Perpetua
Cruz, o Passion de Jesu Christo Nuestro Señor, desde el
principio de su encarnacion hasta su muerte. Representada
en quarenta estampas que se reparten de balde,
y explicada con differentes razones y oraciones de
devocion. En Amberes, en la emprenta de Cornelio Woons,
1650.” The cuts were engraved at the instance of the
Archbishop of Malines. Before the Spanish edition
appeared, thirty thousand copies of the work in Flemish
and Latin had already been circulated.
VI.125 In Walpole’s Catalogue of Engravers there is the
following notice of the elder Switzer: “In the Harleian
Library was a set of wooden cuts, representing the broad
seals of England from the conquest to James I. inclusive,
neatly executed. Vertue says this was the sole impression
he had seen, and believed that they were cut by Chr.
Switzer, and that these plates were copied by Hollar for
Sandford. Switzer also cut the coins and seals in Speed’s
History of Britain, 1614 [1611], from the originals in the
Cottonian Collection. Speed calls him the most exquisite
and curious hand of that age. He probably engraved the
botanic figures for Lobel’s Observations, and the plates
[cuts] for Parkinson’s Paradisus Terrestris, 1629. Chr.
Switzer’s works have sometimes been confounded with his
son’s, who was of both his names.”—Catalogue of
Engravers, p. 18 note, Edit. 1794. It is doubtful if the elder
Switzer’s Christian name were Christopher. The initial in
Parkinson’s Paradisus Terrestris is an A. It is, however,
possible that this letter may be intended for a Latin
preposition, and not for the first letter of the engraver’s
Christian name.
VI.126 The cuts in an edition of “The most Delightful
History of Reynard the Fox,” 4to. London, printed for
Thomas Passinger, 1681, are scarcely superior to this cut in
point of execution, though it must be confessed that the
figures are generally in better “keeping.”
 Illustrations with Text (pages 339-346, 437)
Page 339:
Quia audiſti vocem vxoris tuæ, & comediſti
de ligno ex quo preceperam tibi ne come-
deres &c.
GENESIS III
A D A M fut par E V E deceu
Et contre D I E V mangea la pomm
Dont tous deux out la Mort receu,
Et depuis fut mortel tout homme.
C
Page 341:
Spiritus meus attenuabitur, dies mihi bre-
viabuntur, & ſolum mihi ſupereſt ſepul-
chrum.
IOB XVII
Mes eſperitz ſont attendriz,
Et ma uie ſ’en ua tout beau.
Las mes longz iours ſont amoindriz
Plus ne me reſte qu’un tombeau.
Page 342:
De lectulo ſuper quem aſcendi-
ſti non deſcendes, ſed morte
morieris.
III REG. I
Du lict ſus lequel as monté
Ne deſcendras a ton plaiſir.
Car Mort t’aura tantoſt dompté,
Et en brief te uiendra ſaiſir.
Page 343:
Homo natus de muliere, brevi vivens tempore
repletur multis miſeriis, qui quaſi flos egre-
ditur, & conteritur, & fugit velut umbra.
IOB XIIII
 Tout homme de la femme yſſant
Remply de miſere, & d’encombre,
Ainſi que fleur toſt finiſſant,
Sort & puis fuyt comme faict l’umbre.
Page 344:
Il cheut en son chariot.
I. ROIS IX.
Au passage de MORT perverse
Raison, Chartier tout esperdu,
Du corps le char, & chevaux verse,
Le vin (sang de vie) esperdu.
Page 345:
Il sera percé de sagettes.
EXOD. XIX.
L’eage du sens, du sang l’ardeur
Est legier dard, & foible escu
Contre MORT, qui un tel dardeur
De son propre dard rend vaincu.
Page 346:
Il partira les despoilles avec les puissans.
ISAIE LIII.
Pour les victoires triumphées
Sur les plus forts des humains cœurs,
Les despoilles dresse en trophées
La MORT vaincresse des vainqueurs.
Page 437 (see body text for final six lines of sonnet):
The good | Howſ-holder
The good Howſ-holder, that his Howſe may hold,
Firſt builds it on the Rock, not on the Sand.
Then, with a warie head and charie hand
Pro[v]ides (in tyme) for Hunger and for Cold:
Not daintie Fare and Furniture of Gold,
But handſom-holſom (as with Health dooth ſtand).
Not for the Rich that can as much command
But the poor Stranger, th’Orfan & the Old.
PRINTED AT LON
DON IN THE
BLACKE
FRIERS.
1607

Errors in Chapter VI
10. Die Keyserinn.—The Empress.
anomalous . in original
To England straightway let him send,
n in “send” invisible
When Mr. Douce stated that it was
Mr Douce
It strikingly exemplifies Mr. Douce’s eagerness
Mr Douce’s
forms the tail-piece at the end of the volume.
tailpiece
[VI-121]
footnote tag missing: best guess

Introduction (separate file)

List of Illustrations (separate file)
Chapter I (separate file)
Chapter II (separate file)
Chapter III (separate file)
Chapter IV (separate file)
Chapter V (separate file)
Chapter VI
Chapter VII (separate file)
Chapter VIII (separate file)
Chapter IX (separate file)
Index (separate file)
 Introduction (separate file)
List of Illustrations (separate file)
Chapter I (separate file)
Chapter II (separate file)
Chapter III (separate file)
Chapter IV (separate file)
Chapter V (separate file)
Chapter VI (separate file)
Chapter VII
Chapter VIII (separate file)
Chapter IX (separate file)
Index (separate file)
 ON

WOOD ENGRAVING.

446
CHAPTER VII.
REVIVAL OF WOOD ENGRAVING.

English wood-cuts in 1712—howel’s medulla historiæ anglicanæ—

maittaire’s classics 1713—e. kirkall—his chiaro-scuros—cuts in
croxall’s æsop, 1722—j. b. jackson—chiaro-scuros engraved by him at
venice, 1738-1742—french wood engravers, 1710-1768; j. m. papillon,

m. le sueur, and p. s. fournier—english wood-cuts, 1760-1772—cuts in

sir john hawkins’s history of music, 1776—thomas bewick—his first

wood-cuts, in hutton’s mensuration, 1768-1770—cuts by him in a

hieroglyphic bible—in fables, 1779-1784—his cut of the chillingham

bull—his quadrupeds, british birds, and fables—john bewick—cuts by him

in emblems of mortality, and other books—poems by goldsmith and parnell

—somerviles’s chase—robert johnson, designer of several of the tail-

pieces in bewick’s works—charlton nesbit—luke clennell—william harvey

—robert branston—john thompson, and others.

 LTHOUGH wood engraving had fallen into
almost utter neglect by the end of the
seventeenth century, and continued in a
languishing state for many years afterward,
yet the art was never lost, as some persons
have stated; for both in England and in France
a regular succession of wood engravers can
be traced from 1700 to the time of Thomas
Bewick. The cuts which appear in books
printed in Germany, Holland, and Italy during the same period,
though of very inferior execution, sufficiently prove that the art
continued to be practised in those countries.
The first English book of this period which requires notice is an
edition of Howel’s Medulla Historiæ Anglicanæ, octavo, printed at
London in 1712. VII.1 There are upwards of sixty wood-cuts in this
work, and the manner in which they are executed sufficiently 447
indicates that the engraver must have either been self-taught or the
pupil of a master who did not understand the art. The blocks have,
for the most part, been engraved in the manner of copper-plates;
most of the lines, which a regular wood engraver would have left in
relief, are cut in intaglio, and hence in the impression they appear
white where they ought to be black. The bookseller, in an address to
the reader, thus proceeds to show the advantages of those cuts, and
to answer any objection that might be urged against them on
account of their being engraved on wood. “The cuts added in this
edition are intended more for use than show. The utility consists in
these two particulars. 1. To make the better impression on the
memory. 2. To show more readily when the notable passages in our
history were transacted; which, without the knowledge of the names
of the persons, are not to be found out, by even the best indexes.
As for example: In what reign was it that a rebellious rout, headed
by a vile fellow, made great ravage, and appearing in the King’s
presence with insolence, their captain was stabbed upon the spot by
the Lord-Mayor? Here, without knowing the names of some of the
parties, which a world of people are ignorant of, the story is not to
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

textbookfull.com