Software Architecture 14th European

Conference ECSA 2020 L Aquila Italy

September 14 18 2020 Proceedings
Anton Jansen
Visit to download the full and correct content document:
https://textbookfull.com/product/software-architecture-14th-european-conference-ecs
a-2020-l-aquila-italy-september-14-18-2020-proceedings-anton-jansen/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...

Software Architecture 12th European Conference on

Software Architecture ECSA 2018 Madrid Spain September
24 28 2018 Proceedings Carlos E. Cuesta

https://textbookfull.com/product/software-architecture-12th-
european-conference-on-software-architecture-ecsa-2018-madrid-
spain-september-24-28-2018-proceedings-carlos-e-cuesta/

Software Architecture 13th European Conference ECSA

2019 Paris France September 9 13 2019 Proceedings Tomas
Bures

https://textbookfull.com/product/software-architecture-13th-
european-conference-ecsa-2019-paris-france-
september-9-13-2019-proceedings-tomas-bures/

Software Engineering and Formal Methods: 18th

International Conference, SEFM 2020, Amsterdam, The
Netherlands, September 14–18, 2020, Proceedings Frank
De Boer
https://textbookfull.com/product/software-engineering-and-formal-
methods-18th-international-conference-sefm-2020-amsterdam-the-
netherlands-september-14-18-2020-proceedings-frank-de-boer/

Computer Security ESORICS 2020 25th European Symposium

on Research in Computer Security ESORICS 2020 Guildford
UK September 14 18 2020 Proceedings Part II Liqun Chen

https://textbookfull.com/product/computer-security-
esorics-2020-25th-european-symposium-on-research-in-computer-
security-esorics-2020-guildford-uk-
Addressing Global Challenges and Quality Education 15th
European Conference on Technology Enhanced Learning EC
TEL 2020 Heidelberg Germany September 14 18 2020
Proceedings Carlos Alario-Hoyos
https://textbookfull.com/product/addressing-global-challenges-
and-quality-education-15th-european-conference-on-technology-
enhanced-learning-ec-tel-2020-heidelberg-germany-
september-14-18-2020-proceedings-carlos-alario-hoyos/

Wireless Sensor Networks 14th China Conference CWSN

2020 Dunhuang China September 18 21 2020 Revised
Selected Papers Zhanjun Hao

https://textbookfull.com/product/wireless-sensor-networks-14th-
china-conference-cwsn-2020-dunhuang-china-
september-18-21-2020-revised-selected-papers-zhanjun-hao/

Computer Algebra in Scientific Computing 22nd

International Workshop CASC 2020 Linz Austria September
14 18 2020 Proceedings François Boulier

https://textbookfull.com/product/computer-algebra-in-scientific-
computing-22nd-international-workshop-casc-2020-linz-austria-
september-14-18-2020-proceedings-francois-boulier/

Business Process Management: 18th International

Conference, BPM 2020, Seville, Spain, September 13–18,
2020, Proceedings Dirk Fahland

https://textbookfull.com/product/business-process-
management-18th-international-conference-bpm-2020-seville-spain-
september-13-18-2020-proceedings-dirk-fahland/

Advances in Practical Applications of Agents Multi

Agent Systems and Trustworthiness The PAAMS Collection
18th International Conference PAAMS 2020 L Aquila Italy
October 7 9 2020 Proceedings Yves Demazeau
https://textbookfull.com/product/advances-in-practical-
applications-of-agents-multi-agent-systems-and-trustworthiness-
the-paams-collection-18th-international-conference-
 Anton Jansen · Ivano Malavolta ·
Henry Muccini · Ipek Ozkaya ·
Olaf Zimmermann (Eds.)
LNCS 12292

Software
Architecture
14th European Conference, ECSA 2020
L’Aquila, Italy, September 14–18, 2020
Proceedings
Lecture Notes in Computer Science 12292

Founding Editors
Gerhard Goos
Karlsruhe Institute of Technology, Karlsruhe, Germany
Juris Hartmanis
Cornell University, Ithaca, NY, USA

Editorial Board Members

Elisa Bertino
Purdue University, West Lafayette, IN, USA
Wen Gao
Peking University, Beijing, China
Bernhard Steffen
TU Dortmund University, Dortmund, Germany
Gerhard Woeginger
RWTH Aachen, Aachen, Germany
Moti Yung
Columbia University, New York, NY, USA
More information about this series at http://www.springer.com/series/7408
Anton Jansen Ivano Malavolta
• •

Henry Muccini Ipek Ozkaya

• •

Olaf Zimmermann (Eds.)

Software
Architecture
14th European Conference, ECSA 2020
L’Aquila, Italy, September 14–18, 2020
Proceedings

123
Editors
Anton Jansen Ivano Malavolta
Koninklijke Philips N.V. VU Amsterdam
Eindhoven, The Netherlands Amsterdam, The Netherlands
Henry Muccini Ipek Ozkaya
University of L’Aquila Carnegie Mellon University
L’Aquila, Italy Pittsburg, PA, USA
Olaf Zimmermann
University of Applied Sciences
of Eastern Switzerland
Rapperswil, Switzerland

ISSN 0302-9743 ISSN 1611-3349 (electronic)

Lecture Notes in Computer Science
ISBN 978-3-030-58922-6 ISBN 978-3-030-58923-3 (eBook)
https://doi.org/10.1007/978-3-030-58923-3
LNCS Sublibrary: SL2 – Programming and Software Engineering

© Springer Nature Switzerland AG 2020

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are
believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors
give a warranty, expressed or implied, with respect to the material contained herein or for any errors or
omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in
published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
 Preface

The European Conference on Software Architecture (ECSA) is the premier European

conference that provides researchers and practitioners with a platform to present and
discuss the most recent, innovative, and significant findings and experiences in the field
of software architecture research and practice. This 14th edition of ECSA builds upon a
series of successful European workshops on software architecture held during
2004–2006, as well as a series of European software architecture conferences during
2007–2019. This edition of ECSA had a unique nature as due to the novel coronavirus,
COVID-19, it was the first ECSA conference that was originally to be held in L’Aquila,
Italy, but convened the participants around the globe virtually during September 14–18,
2020.
This year’s technical program included a main research track, three keynote talks,
and an industry track (included in this volume), as well as a doctoral symposium track
with its own keynote, a gender diversity in software architecture track with its own
keynote, and a tool demos track. In addition, ECSA 2020 also offered nine workshops
on diverse topics related to the software architecture discipline, such as automotive
architectures, quality-aware DevOps, and IoT systems. In addition, ECSA 2020 fea-
tured a journal first track partnering with the Journal of Software and Systems, Elsevier,
and the IEEE Software Magazine. The contributions of all these other meetings are
included in the companion proceedings, published in a volume by Springer CCIS.
ECSA 2020 received 103 contributions to all tracks. For the main research track, we
received 60 submissions in the two main categories: full and short research papers.
Based on the recommendations of the Program Committee, we accepted 12 papers as
full papers and 5 additional papers as short papers. Hence the acceptance rate for full
research papers was 20% for ECSA 2020. For the industrial track, we received 11
submissions and accepted 6 of them. The conference attracted papers (co-)authored by
researchers, practitioners, and academia from 24 countries (Austria, Australia, Brazil,
Canada, Chile, Columbia, Denmark, Ecuador, Finland, France, Germany, Italy, the
Netherlands, New Zealand, Spain, Pakistan, Poland, Portugal, Romania, Sweden,
Switzerland, Tunisia, the UK, and the USA).
The main ECSA program had three keynotes. Professor Ivica Crnkovic from
Chalmers University, Sweden, talked about “AI engineering—new challenges in sys-
tem and software architecting and managing lifecycle for AI-based systems.” Professor
Diomidis Spinellis, from Athens University of Economics and Business, Greece, gave
a presentation on “Fifty years of sustained progress: Form, forces, and lessons of Unix
architectural evolution.” The industry keynote was delivered by Michael Keeling, an
experienced software engineer and the author of the book “Design It! From Pro-
grammer to Software Architect.”
We are grateful to the members of the Program Committee for helping us to seek
submissions and provide valuable and timely reviews. Their efforts enabled us to put
together a high-quality technical program for ECSA 2020. We would like to thank the
vi Preface

members of the Organizing Committee of ECSA 2020 for playing an enormously

important role in successfully organizing the event with several tracks and collocated
events, as well as the workshop organizers, who made significant contributions to this
year’s successful event.
We also thank our sponsors who provided financial support for the event: the
University of L’Aquila, Italy, provided the technology infrastructure and the support
needed, nExpecto, and Springer.
The ECSA 2020 submission and review process was supported by the EasyChair
conference management system. We acknowledge the prompt and professional support
from Springer who published these proceedings in electronic volumes as part of the
Lecture Notes in Computer Science series. Finally, we would like to thank the authors
of all the ECSA 2020 submissions and the attendees of the conference for their
participation.
ECSA 2020 planning and execution took place during an unprecedented time in our
history, globally we had to face a pandemic as well as understand and react to con-
sequences of systematic racism and intolerance. As the ECSA community, we pledge
to stand against racism and intolerance and strive to elevate the ideas and voices of
black, indigenous, and people of color who have been historically excluded because of
systemic racism.
We thank the support of the software architecture community, they reacted by
continuing to advance the field of software architecture through their scientific sub-
missions to ECSA, while staying flexible as the Organizing Committee had to pivot
several times from an in-person, to hybrid, to an all-online conference.

July 2020 Anton Jansen

Ivano Malavolta
Henry Muccini
Ipek Ozkaya
Olaf Zimmermann
 Organization

General Chair
Henry Muccini University of L’Aquila, Italy

Steering Committee
Muhammad Ali Babar The University of Adelaide, Australia
Paris Avgeriou University of Groningen, The Netherlands
Tomas Bures Charles University, Czech Republic
Rogério de Lemos University of Kent, UK
Laurence Duchien CRIStAL, University of Lille, France
Carlos E. Cuesta Rey Juan Carlos University, Spain
David Garlan Carnegie Mellon University, USA
Paola Inverardi University of L’Aquila, Italy
Patricia Lago Vrije Universiteit Amsterdam, The Netherlands
Antónia Lopes University of Lisbon, Portugal
Ivano Malavolta Vrije Universiteit Amsterdam, The Netherlands
Raffaela Mirandola Politecnico di Milano, Italy
Henry Muccini University of L’Aquila, Italy
Flavio Oquendo (Chair) IRISA, University of South Brittany, France
Ipek Ozkaya Carnegie Mellon University, USA
Jennifer Pérez Technical University of Madrid, Spain
Bedir Tekinerdogan Wageningen University, The Netherlands
Danny Weyns KU Leuven, Belgium
Uwe Zdun University of Vienna, Austria

Research Track
Program Committee Chairs
Ivano Malavolta Vrije Universiteit Amsterdam, The Netherlands
Ipek Ozkaya Carnegie Mellon University, USA

Program Committee
Jesper Andersson Linnaeus University, Sweden
Paris Avgeriou University of Groningen, The Netherlands
Rami Bahsoon University of Birmingham, UK
Luciano Baresi Politecnico di Milano, Italy
Thais Batista Federal University of Rio Grande do Norte, Brazil
Steffen Becker University of Stuttgart, Germany
Stefan Biffl TU Wien, Austria
viii Organization

Barbora Buhnova Masaryk University, Czech Republic

Tomas Bures Charles University, Czech Republic
Javier Cámara University of York, UK
Rafael Capilla Rey Juan Carlos University, Spain
Jan Carlson Malardalen University, Sweden
Siobhán Clarke Trinity College Dublin, Ireland
Vittorio Cortellessa University of L’Aquila, Italy
Carlos Cuesta Rey Juan Carlos University, Spain
Rogerio De Lemos University of Kent, UK
Elisabetta Di Nitto Politecnico di Milano, Italy
Andres Diaz Pace UNICEN University, Argentina
Khalil Drira LAAS-CNRS, France
Laurence Duchien University of Lille, France
Neil Ernst University of Victoria, Canada
George Fairbanks Google, USA
Matthias Galster University of Canterbury, New Zealand
Ilias Gerostathopoulos TU Munich, Germany
Carlo Ghezzi Politecnico di Milano, Italy
Volker Gruhn Universität Duisburg-Essen, Germany
Petr Hnetynka Charles University, Czech Republic
Paola Inverardi University of L’Aquila, Italy
Pooyan Jamshidi University of South Carolina, USA
Wouter Joosen KU Leuven, Belgium
Anne Koziolek Karlsruhe Institute of Technology, Germany
Heiko Koziolek ABB Corporate Research, Germany
Patricia Lago Vrije Universiteit Amsterdam, The Netherlands
Nuno Laranjerio University of Coimbra, Portugal
Nicole Levy CNAM, France
Grace Lewis Carnegie Mellon University, USA
Antónia Lopes University of Lisbon, Portugal
Kristina Lundquist Malardalen University, Sweden
Sam Malek University of California, Irvine, USA
Tomi Männistö University of Helsinki, Finland
Antonio Martini University of Oslo, Norway
Tommi Mikkonen University of Helsinki, Finland
Mehdi Mirakhorli Rochester Institute of Technology, USA
Raffaela Mirandola Politecnico di Milano, Italy
Marina Mongiello Politecnico di Bari, Italy
Gabriel Moreno Carnegie Mellon University, USA
Juan Manuel Murillo University of Extremadura, Spain
Elisa Yumi Nakagawa University of São Paulo, Brazil
Elena Navarro University of Castilla-La Mancha, Spain
Flavio Oquendo Université Bretagne Sud, France
Claus Pahl Free University of Bozen-Bolzano, Italy
Liliana Pasquale University College Dublin, LERO, Ireland
Cesare Pautasso USI Lugano, Switzerland
 Organization ix

Patrizio Pelliccione Chalmers University of Technology, Sweden

Jennifer Perez Universidad Politécnica de Madrid, Spain
Claudia Raibulet University of Milano-Bicocca, Italy
Maryam Razavian Eindhoven University of Technology, The Netherlands
Ralf Reussner Karlsruhe Institute of Technology, Germany
Bradley Schmerl Carnegie Mellon University, USA
Romina Spalazzese Malmö University, Sweden
Girish Suryanarayana Siemens Corporate Technology, India
Bedir Tekinerdogan Wageningen University, The Netherlands
Chouki Tibermacine University of Montpellier, France
Rainer Weinreich Johannes Kepler University Linz, Austria
Danny Weyns KU Leuven, Belgium
Uwe Zdun University of Vienna, Austria
Liming Zhu The University of New South Wales, Australia
Olaf Zimmermann Hochschule für Technik Rapperswill, Switzerland

Additional Reviewers

Anastase Adonis Axel Legay

Abdulatif Alabdulatif Samir Ouchani
Maria Istela Cagnin Eduardo Silva
Everton Cavalcante Roberto Verdecchia
Milena Guessi

Industry Track
Program Committee Chairs
Anton Jansen Philips, The Netherlands
Olaf Zimmermann Hochschule für Technik Rapperswil, Switzerland

Program Committee
Mohsen Anvaari Independent Consultant, Norway
Andrei Furda Hitachi Rail STS, Australia
Heiko Koziolek ABB Corporate Research, Germany
Thomas Kurpick Trusted Shops, Germany
Xabier Larrucea Tecnalia, Spain
Daniel Lübke iQuest GmbH, Germany
Željko Obrenović Incision, The Netherlands
Eltjo Poort CGI, The Netherlands
Daniele Spinosi Micron Technology, Italy
Michael Stal Siemens, Germany
Johannes Wettinger Bosch, Germany
Erik Wittern IBM T.J. Watson Research Center, USA
Eoin Woods Endava, UK
x Organization

Additional Reviewers

Stefan Kapferer
Mirko Stocker

Organizing Committee
Proceedings Chair
Mirco Franzago University of L’Aquila, Italy

Web Chair
Karthik Vaidhyanathan Gran Sasso Science Institute, Italy

Tool Demos Chairs

Paris Avgeriou University of Groningen, The Netherlands
Barbora Buhnova Masaryk University, Czech Republic

Gender Diversity in SA Chairs

Javier Camara University of York, UK
Catia Trubiani Gran Sasso Science Institute, Italy

Doctoral Symposium Chairs

Patrizia Scandurra DIIMM, University of Bergamo, Italy
Danny Weyns KU Leuven, Belgium

Workshops Chairs
Mauro Caporuscio Linnaeus University, Sweden
Anne Koziolek Karlsruhe Institute of Technology, Germany

Journal First Chair

Uwe Zdun University of Vienna, Austria

Publicity Chairs
Stéphanie Challita Inria, France
Juergen Musil TU Wien, Austria

Student Volunteer Chairs

Roberta Capuano University of L’Aquila, Italy
Jamal El Hecham IRISA, France
 Organization xi

Virtualization Chairs
Claudio Di Sipio University of L’Aquila, Italy
Luca Traini University of L’Aquila, Italy
Keynotes
 AI Engineering — New Challenges in System
and Software Architecting and Managing
Lifecycle for AI-based Systems

Ivica Crnkovic

Chalmers University, Gothenburg, Sweden

ivica.crnkovic@chalmers.se

Abstract. Artificial Intelligence based on Machine Learning, and in particular

Deep Learning, is today the fastest growing trend in software development, and
literally used in all other research disciplines, with a very high impact on the
modern society. However, a wide use of AI in many systems, in particular
dependable systems, is still far away of being widely used. On the one hand
there is a shortage of expertise, on the other hand the challenges for managing
AI-based complex and dependable systems are enormous, though less known,
and in general underestimated. Some aspects of these challenges are based on
management of resources, including computational, data storage capacity, per-
formance, and real-time constraints. Introduction of AI-based components, i.e.
components that includes AI algorithms, require significant changes in system
and software architecture, and its successful deployment is based on many
architectural decisions and on changes of the development process.
This talk discusses some of these challenges, illustrate a case of
Cyber-physical systems, and gives some ideas for new research in software
engineering inducing software architecture, i.e. for AI engineering.

Short Bio

Ivica Crnkovic is a professor of software engineering at Chalmers University,

Gothenburg, Sweden. He is the director of ICT Area of Advance at Chalmers
University, and the director of Chalmers AI Research Centre (CHAIR). His research
interests include, software architecture, software development processes, software
engineering for large complex systems, component-based software engineering, and
recently Software engineering for AI. Professor Crnkovic is the author of more than
200 refereed publications on software engineering topics, and guest editor of a number
of special issues in different journals and magazines, such as IEEE Software, and
Elsevier JSS. He was the general chair of 40th International Conference on Software
Engineering (ICSE) 2018, held in Gothenburg, 2018. Before Chalmers, Ivica Crnkovic
was affiliated with Mälardalen University, Sweden, and before that he was employed at
ABB company, Sweden, where he was responsible for software development envi-
ronments and tools.
More information is available on http://www.ivica-crnkovic.net
 Fifty Years of Sustained Progress: Form,
Forces, and Lessons of Unix Architectural
Evolution

Diomidis Spinellis

Department of Management Science and Technology,

Athens University of Economics and Business, Greece
dds@aueb.gr

Abstract. Unix has evolved over five decades, shaping modern operating sys-
tems, key software technologies, and development practices. Studying the
evolution of this remarkable system from an architectural perspective can pro-
vide insights on how to manage the growth of large, complex, and long-lived
software systems. Along main Unix releases leading to the FreeBSD lineage we
examine core architectural design decisions, the number of features, and code
complexity, based on the analysis of source code, reference documentation, and
related publications. We see that the growth in size has been uniform, with some
notable outliers, while cyclomatic complexity has been religiously safeguarded.
A large number of Unix-defining design decisions were implemented right from
the very early beginning, with most of them still playing a major role. Unix
continues to evolve from an architectural perspective, but the rate of architec-
tural innovation has slowed down over the system’s lifetime. Architectural
technical debt has accrued in the forms of functionality duplication and unused
facilities, but in terms of cyclomatic complexity it is systematically being paid
back through what appears to be a self-correcting process. Some unsung
architectural forces that shaped Unix are the emphasis on conventions over rigid
enforcement, the drive for portability, a sophisticated ecosystem of other
operating systems and development organizations, and the emergence of a
federated architecture, often through the adoption of third-party subsystems.
These findings allow us to form an initial theory on the architecture evolution of
large, complex operating system software.

Short Bio

Diomidis Spinellis is a Professor in the Department of Management Science and

Technology at the Athens University of Economics and Business, Greece. His research
interests include software engineering, IT security, and cloud systems engineering. He
has written two award-winning, widely- translated books: “Code Reading” and “Code
Quality: The Open Source Perspective”. His most recent book is “Effective Debugging:
66 Specific Ways to Debug Software and Systems”. Dr. Spinellis has also published
more than 300 technical papers in journals and refereed conference proceedings, which
have received more than 8000 citations. He served for a decade as a member of the
 Fifty Years of Sustained Progress: Form, Forces, and Lessons of Unix xvii

IEEE Software editorial board, authoring the regular “Tools of the Trade” column, and
as the magazine’s Editor-in- Chief over the period 2015–2018. He has contributed code
that ships with Apple’s macOS and BSD Unix and is the developer of UMLGraph,
CScout, git-issue, and other open-source software packages, libraries, and tools.
Dr. Spinellis is a senior member of the ACM and the IEEE.
 Mighty Methods: Four Essential Tools
for Every Software Architect’s Silver Toolbox

Michael Keeling

LendingHome, USA
mkeeling@neverletdown.net

Abstract. It is an oversimplification to say that we are living in extraordinary

times. When my team was first asked to work from home back in February we
were happy to do our part in attempting to stem the tide of an inevitable global
pandemic. While we were eager to help, we were also nervous about how
suddenly distributing our co-located team would affect our way of working. And
yet, after several months we’ve settled into a “new normal” that looks sur-
prisingly similar to our way of working from Before. Much about how we
worked changed, in some cases dramatically, but a handful of design methods
that were central to our team remained effective even after the shift from a
co-located to fully distributed context. In particular, mob programming, example
mapping, architecture decision records, and visual thinking are consistently
among the most versatile and reliable tools in my silver toolbox.
In this talk we’ll briefly explore these four methods and speculate about what
makes them effective tools for software architects in such a broad range of
contexts and situations. While this is not a talk about remote work per se, we’ll
attempt to use the shifting context of work we’ve all experienced to further
isolate variables that might help us identify other potential mighty methods
waiting for software architects to adopt.

Short Bio

Michael Keeling is a software engineer at LendingHome and the author of Design It!:
From Programmer to Software Architect. Prior to LendingHome, Keeling worked at
IBM on the Watson Discovery Service, Vivisimo, BuzzHoney, and Black Knight
Technology. Keeling has also served as an Adjunct Faculty member at Carnegie
Mellon University in the Master of Software Engineering Distance Program since
2009. He holds a Master in Software Engineering from Carnegie Mellon University in
Pittsburgh, PA and a Bachelor of Science in Computer Science from the College of
William and Mary in Williamsburg, VA.
Keeling’s current research interests include software architecture design methods,
agile software development, and human factors of software engineering. He is a regular
speaker in the architecture and agile communities, presenting papers and talks, and
facilitating workshops for both national and international audiences. Keeling is a
two-time winner of the SEI/IEEE Software “Architecture in Practice” Best Presentation
Award for talks given at the 2012 and 2014 SATURN conferences. A full list of his
talks and workshops are available on his website:
http://www.neverletdown.net/p/speaking-and-writing.html.
 Contents

Microservices

Assessing Architecture Conformance to Coupling-Related Patterns

and Practices in Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Evangelos Ntentos, Uwe Zdun, Konstantinos Plakidas,
Sebastian Meixner, and Sebastian Geiger

Formal Software Architectural Migration Towards Emerging

Architectural Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Nacha Chondamrongkul, Jing Sun, and Ian Warren

Monolith Migration Complexity Tuning Through the Application

of Microservices Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
João Franscisco Almeida and António Rito Silva

Uncertainty, Self-adaptive, and Open System

Decentralized Architecture for Energy-Aware Service Assembly . . . . . . . . . . 57

Mauro Caporuscio, Mirko D’Angelo, Vincenzo Grassi,
and Raffaela Mirandola

Continuous Experimentation for Automotive Software on the Example

of a Heavy Commercial Vehicle in Daily Operation . . . . . . . . . . . . . . . . . . 73
Federico Giaimo and Christian Berger

Towards Using Probabilistic Models to Design Software Systems

with Inherent Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Alex Serban, Erik Poll, and Joost Visser

Model-Based Approaches

Empowering SysML-Based Software Architecture Description with Formal

Verification: From SysADL to CSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Fagner Dias, Marcel Oliveira, Thais Batista, Everton Cavalcante,
Jair Leite, Flavio Oquendo, and Camila Araújo

A Flexible Architecture for Key Performance Indicators Assessment

in Smart Cities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Martina De Sanctis, Ludovico Iovino, Maria Teresa Rossi,
and Manuel Wimmer
xx Contents

Performance and Security Engineering

A Multi-objective Performance Optimization Approach

for Self-adaptive Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Davide Arcelli

Data Stream Operations as First-Class Entities in Component-Based

Performance Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Dominik Werle, Stephan Seifermann, and Anne Koziolek

Architecture-Centric Support for Integrating Security Tools

in a Security Orchestration Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Chadni Islam, Muhammad Ali Babar, and Surya Nepal

VisArch: Visualisation of Performance-based Architectural Refactorings . . . . 182

Catia Trubiani, Aldeida Aleti, Sarah Goodwin, Pooyan Jamshidi,
Andre van Hoorn, and Samuel Gratzl

Architectural Smells and Source Code Analysis

An Initial Study on the Association Between Architectural Smells

and Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Sebastian Herold

Architectural Technical Debt: A Grounded Theory . . . . . . . . . . . . . . . . . . . 202

Roberto Verdecchia, Philippe Kruchten, and Patricia Lago

Does BERT Understand Code? – An Exploratory Study on the Detection

of Architectural Tactics in Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Jan Keim, Angelika Kaplan, Anne Koziolek, and Mehdi Mirakhorli

Education and Training

Teaching Students Software Architecture Decision Making. . . . . . . . . . . . . . 231

Rafael Capilla, Olaf Zimmermann, Carlos Carrillo,
and Hernán Astudillo

The PDEng Program on Software Technology: Experience Report

on a Doctorate Level Architecture Training Program . . . . . . . . . . . . . . . . . . 247
Ad T. M. Aerts and Yanja Dajsuren

Experiences and Learnings from Industrial Case Studies

Architectural Concerns for Digital Twin of the Organization. . . . . . . . . . . . . 265

Mauro Caporuscio, Farid Edrisi, Margrethe Hallberg,
Anton Johannesson, Claudia Kopf, and Diego Perez-Palacin
 Contents xxi

Quick Evaluation of a Software Architecture Using the Decision-Centric

Architecture Review Method: An Experience Report . . . . . . . . . . . . . . . . . . 281
Pablo Cruz, Luis Salinas, and Hernán Astudillo

The Quest for Introducing Technical Debt Management in a Large-Scale

Industrial Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Somayeh Malakuti and Sergey Ostroumov

Architecting Contemporary Distributed Systems

Determining Microservice Boundaries: A Case Study Using Static

and Dynamic Software Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Tiago Matias, Filipe F. Correia, Jonas Fritzsch, Justus Bogner,
Hugo S. Ferreira, and André Restivo

IAS: An IoT Architectural Self-adaptation Framework . . . . . . . . . . . . . . . . . 333

Mahyar T. Moghaddam, Eric Rutten, Philippe Lalanda,
and Guillaume Giraud

A Comparison of MQTT Brokers for Distributed IoT Edge Computing . . . . . 352

Heiko Koziolek, Sten Grüner, and Julius Rückert

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Microservices
 Assessing Architecture Conformance
to Coupling-Related Patterns
and Practices in Microservices

Evangelos Ntentos1(B) , Uwe Zdun1 , Konstantinos Plakidas1 ,

Sebastian Meixner2 , and Sebastian Geiger2
1
Faculty of Computer Science, Research Group Software Architecture,
University of Vienna, Vienna, Austria
{Evangelos.Ntentos,Uwe.Zdun,Konstantinos.Plakidas}@univie.ac.at
2
Siemens Corporate Technology, Vienna, Austria
{Sebastian.Meixner,Sebastian.Geiger}@siemens.com

Abstract. Microservices are the go-to architectural style for building

applications that are polyglot, support high scalability, independent
development and deployment, and are rapidly adaptable to changes.
Among the core tenets for a successful microservice architecture is high
independence of the individual microservices, i.e. loose coupling. A num-
ber of patterns and best practices are well-established in the literature, but
most actual microservice-based systems do not, as a whole or in part, con-
form to them. Assessing this conformance manually is not realistically pos-
sible for large-scale systems. This study aims to provide the foundations
for an automated approach for assessing conformance to coupling-related
patterns and practices specific for microservice architectures. We propose
a model-based assessment based on generic, technology-independent met-
rics, connected to typical design decisions encountered in microservice
architectures. We demonstrate and assess the validity and appropriate-
ness of these metrics by performing an assessment of the conformance of
real-world systems to patterns through statistical methods.

1 Introduction

Microservice architectures [14,15,22] describe an application as a collection of

autonomous and loosely coupled services, typically modeled around a domain.
Key microservice tenets are development in independent teams, cloud-native
technologies and architectures, polyglot technology stacks including polyglot
persistence, lightweight containers, loosely coupled service dependencies, high
releasability, and continuous delivery [22]. Many architectural patterns that
reflect recommended “best practices” in a microservices context have already
been published in the literature [18,19,23]. The fact that microservice-based
systems are complex and polyglot means that an automatic or semi-automatic
assessment of their conformance to these patterns is difficult: real-world systems
feature combinations of these patterns, and different degrees of violations of the
c Springer Nature Switzerland AG 2020
A. Jansen et al. (Eds.): ECSA 2020, LNCS 12292, pp. 3–20, 2020.
https://doi.org/10.1007/978-3-030-58923-3_1
4 E. Ntentos et al.

same; and different technologies in different parts of the system implement the
patterns in different ways, making the automatic parsing of code and identifica-
tion of the patterns a haphazard process.
This work focuses on describing a method for assessing architecture con-
formance to coupling-related patterns and practices in microservice architec-
tures. Coupling between microservices is caused by existence of dependencies,
e.g. whenever one service calls another service to fulfill a request or share data.
Loose coupling is an established topic in service-oriented architectures [22] but
the application to the specific context of microservice architectures has not, to
our knowledge, been examined so far.
Strong coupling is conflicting with some of the key microservice tenets men-
tioned above. In particular, releasability, which is a highly desirable character-
istic in modern systems due to the emergence of DevOps practices, relies on
the rapid and independent release of individual microservices, and is compro-
mised by strong dependencies between them. For the same reason, development
in independent teams becomes more difficult, and independent deployment of
individual microservices in lightweight containers is also impeded. This work
covers three broad coupling aspects: Coupling through Databases, resulting from
reliance on commonly accessed data via shared databases; Coupling through Syn-
chronous Invocations, resulting from synchronous communication between indi-
vidual services; and Coupling through Shared Services, which arises through the
dependence on common shared services (for details see Sect. 3).
In reality, of course, no microservice system can support all microservice
tenets well at the same time. Rather the architectural decisions for or against the
use of specific patterns and practices must reflect a trade-off between ensuring
the desired tenets and other important quality attributes [12,22]. From these
considerations, this paper aims to study the following research questions:
– RQ1 How can we automatically assess conformance to loose coupling-related
patterns and practices in the context of microservice architecture decision
options?
– RQ2 How well do measures for assessing coupling-related decision options
and their associated tenets perform?
– RQ3 What is a set of minimal elements needed in a microservice architecture
model to compute such measures?
In pursuing of these questions, we surveyed the relevant literature (Sect. 2)
and gathered knowledge sources about established architecture practices and
patterns, their relations and tenets in form of a qualitative study on microser-
vice architectures. This enabled us to create a meta-model for the description
of microservice architectures, which was verified and refined through iterative
application in modelling a number of real-world systems, as outlined in Sect. 4.
We manually assessed all models and model variants on whether each deci-
sion option is supported, thereby deriving an objective ground truth (Sect. 5).
As the basis for an automatic assessment, we defined a number of generic,
technology-independent metrics to measure architecture conformance to the
decision options, i.e. at least one metric per major decision option (Sect. 6).
 Assessing Architecture Conformance 5

These metrics (and combinations thereof) were applied on the models and model
variants to derive a numeric assessment, and then compared to the ground truth
assessment via an ordinal regression analysis (Sect. 7). Section 8 discusses the
results of our approach, as well as its limitations and potential threats to valid-
ity. Finally, in Sect. 9 we draw our conclusions and discuss options for future
work.

2 Related Work
Many studies focus on best practices for microservice architectures. Richard-
son [18] has published a collection of microservice patterns related to major
design and architectural practices. Patterns related to microservice APIs have
been introduced by Zimmermann et al. [23], while Skowronski [19] collected best
practices for event-driven microservice architectures. Microservice fundamentals
and best practices are also discussed by Fowler and Lewis [14], and are summa-
rized in a mapping study by Pahl and Jamshidi [16]. Taibi and Lenarduzzi [20]
study microservice “bad smells”, i.e. practices that should be avoided (which
would correspond to violations in our work).
Many software metrics-related studies for evaluating the system architecture
and individual architectural components exist, but most of them are not specific
to the microservices domain. Allen et al. [1,2] study component metrics for mea-
suring a number of quality attributes, e.g. size, coupling, cohesion, dependencies
of components, and the complexity of the architecture. Additional studies for
assessing quality attributes related to coupling and cohesion have been proposed
and validated in the literature [3,4,6,11]. Furthermore, a small number of stud-
ies [5,17,21] propose metrics specifically for assessing microservice-based soft-
ware architectures. Although these works study various aspects of architecture,
design metrics, and architecture-relevant tenets such as coupling and indepen-
dent deployment, their approach is usually generic. None of the works covers all
the related software aspects for measuring coupling in a microservice context:
the use of databases, system asynchronicity, and shared components. This is the
overarching perspective of our work, and the chief contribution of this paper.

3 Decisions

In this section, we briefly introduce the three coupling-related decisions along

with their decision options (i.e. the relevant patterns and practices) which we
study in this paper. We also discuss the impact on relevant microservice tenets,
which we later on use as an argumentation for our manual ground truth assess-
ment in Sect. 5.
Inter-Service Coupling Through Databases. One important decision in
microservice-based systems is data persistence, which needs to take into account
qualities such as reliability and scalability, but also adhere to microservice-
specific best practices, which recommend that each microservice should be
6 E. Ntentos et al.

loosely coupled and thus able to be developed, deployed, and scaled indepen-
dently [14]. At one extreme of the scale, one option is No Persistent Data Storage,
which is applicable only for services whose functions are performed on transient
data. Otherwise, the most recommended option is the Database per Service pat-
tern [18]: each service has its own database and manages its own data indepen-
dently. Another option, which negatively affects loose coupling, is to use a Shared
Database [18]: a service writes its data in a common database and other services
can read these data when required. There are two different ways to implement
this pattern: in Data Shared via Shared Database multiple services share the
same table, resulting in a strongly coupled system, whereas in Databased Shared
but no Data Sharing each service writes to and reads from its own tables, which
has a lesser impact on coupling.
Inter-Service Coupling Through Synchronous Invocations. Service inte-
gration is another core decision when building a microservice-based system. A
theoretically optimal system of independent microservices would feature no com-
munication between them. Of course, services need to communicate in reality,
and so the question of integrating them so as to not result in tight inter-service
coupling becomes paramount. The recommended practice is that communica-
tion between the microservices should be, as much as possible, asynchronous.
This can be achieved through several patterns which are widely implemented in
typical technology stacks: the Publish/Subscribe [13] pattern, in which services
can subscribe to a channel to which other services can publish; the use of a
Messaging [13] middleware, which decouples communication by using a queue
to store messages sent by the producer until they are received by the consumer;
the Data Polling [18] pattern, in which services periodically poll other services
for data changes; and the Event Sourcing [18] pattern, that ensures that all
changes to application state are stored as a sequence of events; Asynchronous
Direct Invocation technique, in which services communicate asynchronously via
direct invocations. Applying these patterns ensures loose coupling (to different
degrees), and increases the system reliability.
Inter-Service Coupling Through Shared Services. Many of the microser-
vice patterns focus on system structure, i.e. avoiding services sharing other ser-
vices altogether, or at least not in a strongly coupled way. An optimal system
in terms of architecture quality should not have any shared service. In reality,
this is often not feasible, and in larger systems service sharing leads to chains of
transitive dependencies between services. This is problematic when a service is
unaware of its transitive dependencies, and of course for the shared service itself,
where the needs of its dependents must always be taken into account during its
evolution. We define three cases: a Directly Shared Service is a microservice which
is directly linked to and required by more than one other service; a Transitively
Shared Service is a microservice which is linked to other services via at least one
intermediary service; and a Cyclic Dependency [10] which is formed when there
is a direct or transitive path that leads back to its origin, i.e. that allows a ser-
vice to be ultimately dependent on itself after a number of intermediary services.
Cyclic dependencies often emerge inadvertently through increasing complexity
 Assessing Architecture Conformance 7

over the system’s lifecycle, and require extensive refactoring to resolve. All three
cases are inimical to the principle of loose coupling as well as to system qualities
such as performance, modifiability, reusability, and scalability.

4 Research and Modeling Methods

In this section, we summarize the research and modeling methods applied in our
study. The code and models used in and produced as part of this study have
been made available online for reproducibility1 .

4.1 Research Method

Figure 1 shows the research steps from initial data collection to final data anal-
ysis. For the data collection phase we conducted a multi-vocal literature study
using web resources, public repositories, and scientific papers as sources [9]. We
then analyzed the data collected using qualitative methods based on Grounded
Theory [7] coding methods, such as open and axial coding, and extracted the
three core architectural decisions described in the previous section along with
their corresponding decision drivers and impacts. As data for our further research
we used generated models taken from the Model Generation process, described
below. We defined a rating scheme for systematic assessment based on support
or violation of core practices and tenets. From these we derived a ground truth
for our study (the ground truth and its calculation rules are described in Sect. 5)
as well as a set of metrics for automatically calculating conformance to each
individual pattern or practice per decision. We then used the ground truth data
to assess how well the hypothesized metrics can possibly predict the ground
truth data by performing an ordinal regression analysis. Ordinal regression is
a widely used method for modeling an ordinal response’s dependence on a set
of independent predictors, which is applicable in a variety of domains. For the
ordinal regression analysis we used the lrm function from the rms package in
R [8].

4.2 Model Generation

We began by performing an iterative study of a variety of microservice-related
knowledge sources, and we gradually refined a meta-model which contains all the
required elements to help us reconstruct existing microservice-based systems. In
order to investigate the ontology, and to evaluate the meta-model’s efficiency, we
gathered a number of microservice-based systems, summarized in Table 1. Each is
either a system published by practitioners (on GitHub and/or practitioner blogs)
or a system variant adapted from a published example according to discussions in
the relevant literature in order to explore the possible decision space. Apart from
the specific variations described in Table 1 all other system aspects remained the
same as in the base models.
1
https://bit.ly/2WmFP3N.
8 E. Ntentos et al.

Data Collection Phase Data Analysis Architectural Design Decisions

Repositories Formulation of Core Decisions

Extract Ontology (Data

Types) from best practices and
tenets
Research Papers
Data Analysis: Qualitative study
based on Grounded Theory method
Definition of Decision Options:
Patterns and practices
Extraction of Decision Drivers:
Quality attributes/Tenets

Web Resources
Determine Decision Impacts for
each option

Statistical Evaluation Metrics Definition Objective Assessment

Define Metrics for quantifying Establish a Rating Scheme for

extent of support/violation of each
pattern/practice and tenet
Metrics Evaluation: Regression
analysis on ability of the metrics to
predict the ground truth assessment
Automatic Calculation of generated
metrics based on the system
component models
System Assessment: Ordinal scale
based on support or violation of
patterns/practices and tenets
Ground Truth Definition: Manual
assessment of system model
according to rating scheme

Model Generation

Codeable Models System Component

Static Code Analysis Model Visualisation
Generator Model

Fig. 1. Overview diagram of the research method followed in this study

The systems were taken from 9 independent sources in total. They were devel-
oped by practitioners with microservice experience, and they are representative
of the best practices summarized in Sect. 3. We performed a fully manual static
code analysis for those models where the source code was available (7 of our 9
sources; two were modeled from documentation published by the practitioners).
To create our models, we used our existing modeling tool CodeableModels2 , a
Python implementation for the precise specification of meta-models, models, and
model instances in code. Based on CodeableModels, we specified meta-models
for components, connectors and relationships. We then manually created model
instances for each of the systems in Table 1. In addition, we realized automated
constraint checkers and PlantUML code generators to generate graphical visu-
alizations of all meta-models and models.
The result is a set of precisely modeled component models of the examined
software systems (modeled using the techniques described below). This resulted
in a total of 27 models summarized in Table 1. We assume that our evaluation
systems are, or reflect, real-world practical examples of microservice architec-
tures. As many of them are open source systems with the purpose of demon-
strating practices or technologies, they are at most of medium size and modest
complexity, though.
2
https://github.com/uzdun/CodeableModels.
 Assessing Architecture Conformance 9

4.3 Methods for Modeling Microservice Component Architectures

From an abstract point of view, a microservice-based system is composed of
components and connectors, with a set of component types for each compo-
nent and a set of connector types for each connector. For modeling microservice
architectures we followed the method reported in our previous work [21].

5 Ground Truth Calculations

In this section, we present and describe the calculation of the ground truth
assessment for each of the decisions from Sect. 3. The results of those assessments
are reported in Table 2. The assessment begins with a manual evaluation by the
authors on whether each of the relevant patterns (decision options) is either
Supported, Partially Supported, or Not Supported (S, P, N in Table 2). Based
on this and informed by the description of the impacts of the various decision
options in Sect. 3, we combined the outcome of all decision options to derive
an ordinal assessment on how well the decision as a whole is supported in each
model, using the ordinal scale: [ ++: very well supported, +: well supported, o:
neutral, -: badly supported, --: very badly supported]. This was done according
to best practices documented in literature. For instance, following the ordinal
scale the assessment for the model BM1 is +: well supported, since a) option
Database per Service is not supported, b) some services have a shared database,
but c) they do not share data via the shared database.
For the Inter-Service Coupling through Databases decision, we derive the
following scoring scheme for our ground truth assessment:
• ++: All services (which require data persistence) have individual databases
Database per Service.
• +: Some services have Shared Databases and no Data Shared via the Shared
Databases.
• o: All services have Shared Databases and no Data Shared via the Shared
Databases.
• -: Some services have Shared Databases and Data Shared via the Shared
Databases.
• --: All services have Shared Databases and Data Shared via the Shared
Databases.
From the Inter-Service Coupling through Synchronous Invocations decision, we
derive the following scoring scheme for our ground truth assessment:
• ++: All services communicate asynchronously via Message Brokers or Pub-
lish/Subscribe or Stream Processing
• +: All services communicate asynchronously via API Gateway or HTTP
Polling or Direct Asynchronous calls, or (some) via Message Brokers or Pub-
lish/Subscribe or Stream Processing.
• o: None or some services communicate asynchronously and all other services
communicate asynchronously via Data Sharing (e.g. Shared DB).
10 E. Ntentos et al.

Table 1. Overview of modelled systems (size, details, and sources)

Model ID Model Size Description / Source

BM1 10 components Banking-related application based on CQRS and event sourcing (from https://
14 connectors github.com/cer/event-sourcing-examples).
BM2 8 components Variant of BM1 which uses direct RESTful completely synchronous service invocations
9 connectors instead of event-based communication.
BM3 8 components Variant of BM1 which uses direct RESTful completely asynchronous service invocations
9 connectors instead of event-based communication.
CO1 8 components The common component model E-shop application implemented as microservices
9 connectors directly accessed by a Web frontend (from https://github.com/cocome-
community-case-study/cocome-cloud-jee-microservices-rest).
CO2 11 components Variant of CO1 using a SAGA orchestrator on the order service with a message broker.
17 connectors Added support for Open Tracing. Added an API gateway.
CO3 9 components Variant of CO1 where the reports service does not use inter-service communication, but
13 connectors a shared database for accessing product and store data. Added support for Open Tracing.
CI1 11 components Cinema booking application using RESTful HTTP invocations, databases per service,
12 connectors and an API gateway (from https://codeburst.io/build-a-nodejs-
cinema-api-gateway-and-deploying-it-to-docker-\part-4-
703c2b0dd269).
CI2 11 components Variant of CI1 routing all interservice communication via the API gateway.
12 connectors
CI3 10 components Variant of CI1 using direct client to service invocations instead of the API gateway.
11 connectors
CI4 11 components Variant of CI1 with a subsystem exposing services directly to the client and another sub-
12 connectors system routing all traffic via the API gateway.
EC1 10 components E-commerce application with a Web UI directly accessing microservices and an API
14 connectors gateway for service-based API (from https://microservices.io/patterns/
microservices.html).
EC2 11 components Variant of EC1 using event-based communication and event sourcing internally.
14 connectors
EC3 8 components Variant of EC1 with a shared database used to handle all but one service interactions.
11 connectors
ES1 20 components E-shop application using pub/sub communication for event-based interaction, a
36 connectors middleware-triggered identity service, databases per service (4 SQL DBs, 1 Mongo
DB, and 1 Redis DB), and backends for frontends for two Web app types and
one mobile app type (from https://github.com/dotnet-architecture/
eShopOnContainers).
ES2 14 components Variant of ES1 using RESTful communication via the API gateway instead of event-
35 connectors based communication and one shared SQL DB for all 6 of the services using DBs. No
service interaction via the shared database occurs.
ES3 16 components Variant of ES1 using RESTful communication via the API gateway instead of event-
35 connectors based communication and one shared database for all 4 of the services using SQL DB in
ES1. However, no service interaction via the shared database occurs.
FM1 15 components Simple food ordering application based on entity services directly linked to
24 connectors a Web UI (from https://github.com/jferrater/Tap-And-Eat-
MicroServices).
FM2 14 components Variant of FM1 which uses the store service as an API composition and asynchronous
21 connectors interservice communication. Added Jaeger-based tracing per service.
FM3 13 components Variant of FM1 which demonstrates a cyclic dependency case, uses the store service as
15 connectors an API composition and asynchronous inter-service communication
HM1 13 components Hipster shop application using GRPC interservice connection and OpenCensus moni-
25 connectors toring & tracing for all but one services as well as on the gateway. (from https:
//github.com/GoogleCloudPlatform/microservices-demo).
HM2 14 components Variant of HM1 that uses publish/subscribe interaction with event sourcing, except for
26 connectors one service, and realizes the tracing on all services.
RM1 11 components Restaurant order management application based on SAGA messaging and domain
18 connectors event interactions. Rudimentary tracing support (from https://github.com/
microservices-patterns/ftgo-application).
RM2 14 components Variant of RM1 which contains transitively shared services, API Gateway for client ser-
14 connectors vices communication, database per service and direct communication between service.
RM3 14 components Variant of RM1 which demonstrates a cyclic dependency case, API Gateway for client
15 connectors services communication, database per service and direct communication between service.
RS 18 components Robot shop application with various kinds of service interconnections, data stores, and
29 connectors Instana tracing on most services (from https://github.com/instana/robot-
shop).
TH1 14 components Taxi hailing application with multiple frontends and databases per services from
16 connectors (https://www.nginx.com/blog/introduction-to-microservices/).
TH2 15 components Variant of TH1 that uses publish/subscribe interaction with event sourcing for all but one
18 connectors service interactions.
Another random document with
no related content on Scribd:
met A l i n c t h u n in Artesië. Andere plaatsnamen, in hunne
patronymica eenzelvig met A l l i n g t o n en A l i n c t h u n , zijn nog
A l l i n c o u r t (Allinkhove) in de Champagne, en A l l i g n y
(Allingen) in Burgundie, Frankrijk. Verder A l l i n g a w i e r , dorp in
Friesland; A l l i n g a s a t e , boerenhofstede bij het dorp Tietjerk in
Friesland; A l l i n g a h u i z e n , gehucht bij het dorp Winsum in
Groningerland; A l i n g e w o l d e , de oorspronkelijke en volledige
naam, zooals hij in middeneeuwsche oorkonden voorkomt, van het
hedendaagsche A y e n w o l d e , een dorp in Oost-Friesland;
A l l i n g h a u s e n , geh. bij Wald-Broel in Rijn-Pruissen; A l k o f e n ,
oudtijds voluit A l l i n c h o v a , het hof der Allingen, een dorp in
Beieren, enz. Zoo als men ziet, kinderen of afstammelingen van
mannen, die A l e of A l l e geheeten hebben, zijn er in alle
Germaansche landen, Engeland en de Germaansche gewesten van
Frankrijk niet buiten gesloten, overal geweest; en ze zijn daar
blijkens de levende geslachtsnamen, in menigvuldig aantal, nog in
wezen. Even zoo de plaatsnamen, naar A l l e en A l e genoemd.

Maar keeren wij tot de tunnamen terug. Andere zulke namen, als
plaatsnamen zoo veelvuldig in Engeland voorkomende, zijn nog
Eckington, Edington, Alkington, Kensington,
B e n n i n g t o n , S h e r r i n g t o n , en honderden anderen, schier
allen patronymicale namen.

Hoogst opmerkelijk is het, dat plaatsnamen met het woord tun

samengesteld, in andere Germaansche landen bijna geheel
ontbreken, althans zoo hoogst zeldzaam zijn, dat de onvermoeide en
geleerde navorscher Förstemann in zijn Altdeutsches Namenbuch
er slechts een zevental weet aan te wijzen—terwijl zulke namen juist
in Engeland zoo ruimschoots en overtalrijk [106]voorkomen, en ook in
Artesië, het kleine grondgebied in aanmerking genomen, betrekkelijk
even talrijk zijn. Bij de Angel-Sassen maakten deze plaatsnamen wel
een achtste gedeelte uit van alle namen over het geheele land van
dezen volksstam verspreid. Uit dit samentreffen der tunnamen in het
Angelsassische Engeland en in Artesië (terwijl wij die namen te
vergeefs zoeken in het landschap Angelen (in Sleeswijk), in al de
Sassische landen en gouwen van Noordwestelijk Duitschland en
Oostelijk Nederland, in geheel Friesland en Vlaanderen, 4 alle landen
wier ingezeten ten nauwsten met de Angel-Sassen en de Artesiërs
verwant waren of zijn)—uit dit samentreffen mogen wij wel besluiten,
dat er eene nauwe bloedverwantschap, eene oorspronkelijke
eenheid van afkomst bestaan heeft tusschen het Sassische volk dat
in Engeland, en dat hetwelk in Noordwestelijk Frankrijk, aan het later
zoogenoemde Litus saxonicum, dus in het hedendaagsche Artesië
zich heeft neêrgezet.

En even opmerkelijk is het dat de patronymica, voorkomende in de

Artesische tunnamen, met inc (ink) zijn samengesteld
(A l i n c t h u n , To d i n c t h u n ), terwijl de enkelvoudige
patronymica (R i c m a n i n g h e n , W a c q u i n g h e n ) en die welke
hem tot achtervoegsel hebben (L o t t i n g h e m , R u m i n g h e m ),
juist door den vorm ing zijn gekenmerkt. Hiervan is mij geene
uitzondering bekend. Nu weten wij (op bladzijde 98 hiervoren is het
ook reeds vermeld), dat juist de Sassische patronymicaal-vorm ink
is, terwijl de Frankische ing en de Friesche inga is. De patronymica
op ink zijn bijzonder eigen, zoo in geslachts- als in plaatsnamen, aan
de Sassische gouwen van Nederland, terwijl ze in de Frankische en
Friesche gewesten ontbreken, en door ing en inga vervangen zijn.
Het ligt dus voor de hand om aan te nemen, dat het Germaansche,
het Dietsche volk dat Artesië bewoont, [107]en dat de bijzonderheden
zijner oorspronkelijke taal ons in de Artesische plaatsnamen heeft
nagelaten, van tweeërlei stam was, van Sassischen en van
Frankischen of van Frieschen bloede. En tevens dat de Sassen de
tunnamen, de Franken en de Friezen daarentegen de hemnamen,
met de enkelvoudige patronymicale plaatsnamen, hebben in ’t leven
geroepen. Daar is niets, voor zoo verre mij bekend is, dat zich tegen
deze stelling verzet; integendeel, daar is buiten dien nog veel, dat
haar aannemelijk maakt. En zoo straalt hier de namenkunde,
versterkt door de kennis van de eigenheden der volkstaal bij de
verschillende stammen waaruit ons Dietsche volk bestaat, een
verrassend licht uit op de geschiedenis van die volken in die
overoude tijden, waarvan de geschiedboeken zwijgen of slechts
schaars eene spaarzame getuigenis afleggen—overoude tijden,
waaruit geene schriftelijke oorkonden, ter nauwernood enkele vage
overleveringen bestaan. Een licht, dat ons de wegen doet kennen,
die de wandelende volksstammen in dien grauwen voortijd gegaan
zijn, en de landstreken die zij doorgetrokken zijn—een licht, dat de
plaatsen ons doet kennen, waar zij zich eindelijk in vaste
woonsteden blijvend hebben gevestigd, de Sas in zijnen tun, de
Frank en de Fries in zijn hem.

Het moet ons niet verwonderen, dat wij in Artesië, even als ook in
Engeland, de Sassische tun- en de Frankische en Friesche
hemnamen thans naast en nevens elkanderen, als ’t ware onder
elkanderen vermengd vinden. Wij weten immers, dat de benden
volks, de volkplanters of landverhuizers, de uitwijkelingen die
Brittannië veroverden en bevolkten, uit maagschappen, gezinnen en
enkelingen van verschillenden volksaard, uit Sassen, Angelen,
Jutten (of Noord-Friezen) en Friezen waren samengesteld.

Ik stel mij deze zaak aldus voor. In de vijfde eeuw voornamelijk,

maar ook reeds vroeger in de derde en vierde eeuw na Christi
geboorte, trokken lieden uit de verschillende volken die in
Noordwestelijk Germanië waren gezeten, om lotsverbetering te
erlangen, over de Noordzee naar het rijke en vruchtbare, door de
Kelten slechts dun bevolkte Brittannië. Juist zoo, en om de zelfde
redenen, als in deze negentiende eeuw [108]lieden uit allerlei volken
van Europa naar Noord-Amerika trekken. Westwaarts was de leuze,
toen zoowel als nu. Geheele benden volks trokken uit hunne
oorspronkelijke woonsteden aan den zuidelijken oever der Noordzee
en van de meer binnenlands gelegene heidevelden, te scheep
gaande in de monden van Eider, Elve en Weser, van Eems, Lauwers
en Flie, dwars over de Noordzee naar Brittannië, in die tijden het
Land van Beloften. Die reize ging met groote moeilijkheden gepaard,
in aanmerking genomen de kleine en gebrekkige schepen (kielen,
ceola’s of tsjalken), waarmede men zich behelpen moest. Om dit
bezwaar, aan dien tocht over de veelal onstuimige Noordzee
verbonden, zooveel mogelijk te ontgaan, koos men den kortsten
overgang, het nauwste gedeelte der zee, de plek waar de vaste wal
het dichtste tot de oevers van het eiland Brittannië naderde. Met
andere woorden, men koos dat gedeelte van het Engelsche Kanaal,
’t welk de Friesche en Hollandsche zeelieden van onze dagen de
Haden of de Hoofden noemen, en dat in de boeken als het Nauw
van Calais bekend is. Om daar te komen, moesten die uitwijkelingen
uit hunne oostelijke woonsteden langs den zuidelijken oever der
Noordzee west- en zuid-westwaarts voorttrekken. En zoo deden zij.

Zooals boven reeds gezegd is, bestonden die benden

landverhuizers uit allerlei volk, uit leden van verschillende, maar
verwante volksstammen, die elkanderen onderling, met meer of
minder moeite, in ’t spreken verstaan konden. Sassen vormden
zekerlijk wel het hoofdbestanddeel van deze benden, die slechts los
onderling samenhingen, die slechts door den gemeenschappelijk
ondernomen tocht, slechts door het gemeenschappelijke doel
verbonden waren.

Op hunnen tocht door de gewesten, die heden ten dage Holland,

Zeeland, Vlaanderen heeten, kwamen zij hier en daar door weinig
bevolkte of geheel eenzame oorden, die hun genoegzaam
levensonderhoud aanboden, en die, door verlatenheid zoowel als
door vruchtbaarheid, den armen landverhuizers noopten daar voor
goed te blijven. Zoo deed dan ook deze of gene maagschap, dit of
dat gezin, versterkt met den een of anderen, of met meerdere
bevriende enkelingen. Dit is waarschijnlijk de oorsprong, bij
voorbeeld, van het dorp S a s s e n h e i m (woonstede der Sassen,
eene Sassische volkplanting?) in Holland tusschen [109]Haarlem en
Leiden. En tevens van de talrijke sporen van Sassen en Friezen en
Sweven, die de opmerkzame navorscher nog heden in Zeeland en in
West-Vlaanderen en Zee-Vlaanderen ontmoet. Zoo kwamen de
landverhuizers, wier scharen onder weegs reeds aanmerkelijk
gedund waren, wier aantal reeds verminderd was door de
achterblijvers in Holland, Zeeland en Vlaanderen, eindelijk in het
gewest, later Artesië genoemd, waar zij, in hoofdmassa, uit de
overoude havens van Kales en Boonen (Calais en Boulogne sur
Mer), eenen korten en gemakkelijken overtocht naar Brittannië
vonden. Maar geenszins allen trokken over. Het schijnt wel, dat dit
gewest van Gallië, (zoo nabij Brittanië gelegen, en in der daad, in
menig opzicht, wat bodem- en luchtsgesteldheid, ligging, enz.
aangaat, veel overeenkomst met het begeerde Brittenland
aanbiedende) den volke bijzonderlijk behaagde, en hen tot blijven,
tot duurzame vestiging noopte. In der daad, het onderscheid
tusschen dit liefelijke, vruchtbare, heuvelachtige land, langs den
zeeoever zich uitstrekkende, en met eene zachte luchtsgesteldheid
gezegend, was groot tegenover het duistere, voor een goed deel
onvruchtbare, met groote moerassen, sombere venen en met
onafzienbare dorre heiden bedekte, door onophoudelijke
overstroomingen van zee en van riviermonden, en door eene ruwe
luchtsgesteltenis geteisterde land in Noordwestelijk Germanië en op
het Kimbrische schiereiland, het erf van Friezen en Sassen en
Angelen. Hier in Artesië draalden velen eer zij tot den overtocht naar
Brittannië besloten, en velen bleven daar voor goed achter en
vestigden zich in verspreide woonsteden, in tunnen en hemmen over
het geheele land. Dit gezonde, krachtige en eenvoudiglijk levende
volk vermeerderde zich weldra aanmerkelijk in zijne nieuwe
woonstede, op deze vruchtbare velden, die rijkelijk levensonderhoud
verschaften. Het werd het stamvolk van de Dietsche Artesiërs, die
van de jaren 500 en eerder tot 1500 en later, dat geheele land
overdekten, en hunne Dietsche taal alomme deden hooren, wier
plaatsnamen nog heden getuigenis afleggen van den volksaard der
stichters.

Sommige benden uitwijkelingen—waarschijnlijk zij die in wat lateren

tijd kwamen, en Artesië reeds door hunne voorgangers
[110]ingenomen en bezet vonden, trokken nog verder westwaarts
voort, zonder naar Brittannië over te steken, aangelokt door het
schoone en vruchtbare land van Gallië. Al verder en verder
westwaarts, tot zij eindelijk in het hedendaagsche Normandië goede
gelegenheid tot duurzame vestiging vonden. Daar, in de
hedendaagsche Départements Calvados en La Manche vinden wij
bij eenen schrijver van het jaar 843 eene gouw genoemd Otlinga
Saxonica, en Gregorius van Tours meldt, dat aldaar de Saxones
bajocassini wonen. Bajocassini noemt hij deze Sassen, naar de stad
Bajoccas, thans Bayeux geheeten, in die Sassische gouw gelegen,
even als de stad die hedendaags den zeer verbasterden naam van
Caen draagt, maar oudtijds in het oorspronkelijke Germaansch
Catheim of Cathem heette. Hoe langen tijd deze Sassische
volksplanting in het hedendaagsche Normandië nog de
oorspronkelijke Sassische volksspraak in stand heeft gehouden, is
ons niet bekend. Maar de plaatsnamen in deze streek leggen nog
heden ten dage eene onwederlegbare getuigenis af van den
volksaard der lieden, die deze plaatsen gesticht en genoemd
hebben. Als enkele voorbeelden noemen wij, behalven het
bovengenoemde C a t h e m of C a e n nog: S a s s e t o t ,
H e r m a n v i l l e , E t r e h a m voormaals O u i s t r e h a m
genoemd, met L e H a m , C o t t u n , E t a i n h u s , H e u l a n d ,
D o u v r e s , enz. Verder vele patronymicale namen als:
B e r e n g e v i l l e , H a r d i n v a s t , T h o r i g n y, P o t i g n y,
I s i g n y , C a r t i g n y , en anderen.

S a s s e t o t beteekent: woonplaats der Sassen; tot, een aanhangsel

bij plaatsnamen, dat in geheel Normandië veelvuldig voorkomt, is
voluit toft, en behoort bijzonderlijk tot het Skandinavische taaleigen.
Het achtervoegsel ville in H e r m a n v i l l e , B e r e n g e v i l l e ,
B e l l e n g r e v i l l e , B a z e n v i l l e , en meer andere namen in
deze Oud-Sassische gouw, is geenszins het Latijnsche woord villa,
het heden daagsche Fransche ville. Het is eene verbastering van het
Oud-Germaansche woord wiler, hedendaagsch Hoogduitsch weiler,
’t welk een gehucht beteekent. In andere Oud-Germaansche
gouwen van Frankrijk leeft dit woord eveneens nog in plaatsnamen,
onder den vorm villiers; bij voorbeeld H a r d i v i l l i e r s . In
Duitschland zijn de namen die op weiler uitgaan, nog zeer talrijk; die
van de Elsate worden op verschillende wijzen verfranscht:
R a p p o l t s w e i l e r [111]tot R i b e a u v i l l é , G e b w e i l e r tot
G u e b w i l l e r . Dit zelfde algemeen Germaansche aardrijkskundige
woord leeft nog in België als de naam van het dorp W i l d e r e n in
Limburg. En als W y l r e in Nederlandsch-Limburg, tusschen
Maastricht en Aken. Verder nog W y l e r , een dorp tusschen
Nijmegen en Kleef, enz.—O u i s t r e h a m is oorspronkelijk
W e s t e r h a m , de westelijke woonplaats; C o t t u n of C o t u n is
K o e t u i n , omheinde plaats waar binnen men koeien houdt. Ons
woord huis leeft in E t a i n h u s (Steenhuis); H e u l a n d is
Hoogland; D o u v r e s is D e O e v e r s , enz.

Overigens is geheel Normandië overdekt met Germaansche

plaatsnamen; echter zijn dezen niet van Sassischen of anderen
Dietschen oorsprong, maar van de Noormannen afkomstig. De
Noormannen, die dit deel van Gallië veroverden en bevolkten,
hebben de Sassen, welke reeds sedert de derde eeuw daar zaten,
ongemoeid gelaten, als zijnde een verwant Germaansch volk. Zoo
vinden wij heden ten dage Noorsche namen over geheel Normandië,
met uitzondering van de Sassische gouw rondom Bayeux en Caen.

Langs de geheele Fransche kust tusschen Boonen en Bayeux, en

min of meer diep landwaarts in, vinden wij Germaansche
plaatsnamen, waarvan het soms twijfelachtig is of zij van
Noordschen (Skandinavischen), dan wel van Dietschen oorsprong
zijn. Een enkel aardig voorbeeld hier van, moge den lezer voldoende
zijn.

Etretat is de naam van eene badplaats op de kust van Normandië,

die jaarlijks door duizenden weelderige en vermaakzoekende
Parijsenaars bezocht wordt, waarvan wel niemand er aan denkt dat
de namen der plaatsen, die hem daar omringen, niet Fransch, maar
oorspronkelijk Germaansch, Noorsch zijn. Even als in Holland en
Vlaanderen het binnenland door eene duinreeks is afgescheiden van
het zeestrand, zoo neemt in Normandië eene reeks rotsen de plaats
onzer duinen in. Die rotsen heeten daar, en ook in Artesië, les
Falaises, een verfranscht, maar oorspronkelijk Germaansch woord,
dat nog leeft in het Hoogduitsche Fels, rots, steenklip. Door de zee,
door de hevige golfslag, die eeuw uit eeuw in tegen die rotsen of
falaises beukt en dondert, die ze beknaagt en uitspoelt, zijn hier en
daar groote holen en gaten, als poorten, in die steenklippen
gemaakt. De mannen, de visscherliên, maken wel van deze zeer
groote [112]en ruime gaten gebruik, om daar door heen op het strand
en in zee te komen. Twee van die holen, de bijzondersten en
grootsten, dragen te Etretat den zelfden naam, maar in twee talen, in
gedeeltelijk Oud-Germaansch, en in Nieuw-Romaansch. De eene
heet le M a n n e porte, en de ingezetenen van Etretat gebruiken dien
naam nog dagelijks, al verstaan zij hem niet. En de andere heet le
Trou à l’Homme.
Hoe aantrekkelijk de studie der Germaansche plaatsnamen in
Normandië ook moge zijn, wij kunnen haar niet verder vervolgen, en
keeren weêr terug naar Artesië, en naar de tunnamen, van waar wij
zijn uitgegaan op onzen uitstap westwaarts.

Het laatste gedeelte dier namen, tun, genoegzaam verklaard zijnde,

blijft ons het eerste gedeelte, het patronymicon, nog over. Die
patronymica, Warinc, Todinc, Olinc, enz. vertoonen allen oorbeeldige
Sassische vormen; maar de mansnamen W a r e , To d e , O l e ,
waarvan zij zijn afgeleid, liggen niet zoo voor de hand. Dat zijn allen
ingekorte, versletene, verbasterde namen, en ze zijn geenszins allen
gereedelijk in hunne volledige, oorspronkelijke gedaanten aan te
toonen. A l e , den mansnaam, waarvan eerst het patronymicon
Alinc, daarna de plaatsnaam A l i n c t h u n is ontleend, hebben wij
hier voren, op bladz. 105 reeds in zijn oorsprong en verband
nagespeurd. Wij willen dit ook met C o l e doen, met den mansnaam
die aan het patronymicon Colinc, aan den plaatsnaam
C o l i n c t h u n ten grondslag ligt.

Een mansnaam C o l e , C o l e n , K o o l e n was oudtijds in

sommige Nederlandsche gewesten zeer wel bekend en in gebruik,
als ingekorte vorm van den volledigen Kerkelijken naam
N i c o l a u s . Maar daar heeft van oudsher buiten dien nog een
andere, een oorspronkelijk Germaansche mansnaam C o l o
bestaan, die nog leeft in sommige geslachts- en plaatsnamen, hier
en daar in Germaansche landen verspreid. Wat deze naam eigentlijk
beteekent, en met welke andere Germaansche namen hij in verband
staat, is mij niet duidelijk. En van gissingen wensch ik mij hier te
onthouden. Genoeg, dat hij ook nog deel uitmaakt van de volledige
mansnamen C o l o b e r t en C o l o m a n . Veelvuldig in gebruik, en
menigvuldig in samenstellingen is de [113]naam C o l o niet. In
Friesland leefde hij, als K o l e , nog in de jaren 1500. Thans komt hij
nog slechts in afgeleide geslachts- en plaatsnamen voor; te weten
als C o o l s m a en K o o l s m a , ook in den enkelen vorm C o o l en
K o o l , in Friesland; elders in de Nederlanden als C o o l s ,
C o l e n , C o l e n s , C o o l e n ; en, in verkleinvorm K o o l t j e s ;
ook C o l i n c k als patronymicon. In Engeland als C o l e s . Dit zijn
allen geslachtsnamen. Verder in de plaatsnamen: C o l e s h i l l ,
eene stad in Warwickshire, Engeland; K o h l s t ä d t in Lippe-
Detmold (Duitschland), in eene oorkonde van de 11de eeuw
voorkomende als C o l s t i d i ; verder in K ö l l i k e n , in het kanton
Aarau (Zwitserland), samengetrokken uit den volledigen vorm
K o l i n k h o v e n , die onder anderen in eene oorkonde van den jare
864 als C h o l i n c h o v a voorkomt, enz. Eindelijk C o o l s k a m p ,
een dorp in West-Vlaanderen; in eene oude oorkonde wordt deze
naam als C o l e s c a m p vermeld. Maar in den naam van een ander
Westvlaamsch dorp, van C o o l k e r k e , schuilt niet deze Oud-
Germaansche mansnaam. De kerk van dit dorp is aan Sint-Nicolaas
gewijd, en ’t is duidelijk dat de dorpsnaam ontleend is aan den
ingekorten naam van den Patroon der Parochie.

Niet alle tunnamen in het Germaansche Frankrijk zijn met

patronymica samengesteld. Daar zijn nog anderen, als de
opgenoemden. C o t t u n of de Koetuin is reeds op bladz. 111
genoemd. En verder liggen daar in Artesië nog plaatsen, die
Fréthun, Offrethun, Hardenthun, Landrethun,
W i t e r t h u n , R o c t h u n , W a d e n t h u n heeten. Deze namen
zijn ook in hun eerste lid van ontwijfelbaar Germaanschen
oorsprong. Bij het grootste deel dezer namen zal ook wel een
mansnaam, op zich zelven en niet als patronymicon, ten grondslag
liggen. Oude namen vinden wij hier terug, die ons evenzeer uit
Friesche namen, patronymicale geslachtsnamen en anderszins,
bekend zijn: O f f r i n g a en V i t r i n g a (voluit W i t h e r i n g a van
den mansnaam W i t h e r i , W i t e r ) bij voorbeeld.
Het getal van Germaansche plaatsnamen in Artesië is zeer groot en
zeer menigvuldig. Wij moeten nog vermelden:

A u d r e s e l l e s , A r i n g z e l e , T r a m e z e l e . De eerste dezer
namen is verfranscht in zijnen hedendaagschen vorm. Is hij
oorspronkelijk [114]O u d e r z e l e (Ter ouder Zele, woonstede bij de
oude zale of halle) geweest? Dus de zelfde naam die nog eigen is
aan het dorp O u d e z e l e in Fransch-Vlaanderen, en aan het stadje
O l d e n z a a l (ook O l d e n z e e l genoemd) in Twente?
Waarschijnlijk wel.—A r i n g z e l e is weêr een oorbeeldig
Germaansche naam, bestaande uit een patronymicon, met het
bekende woord zele daar achter, dat zoo menigvuldig aan
Vlaamsche plaatsnamen eigen is. De mansnaam, die aan dit
patronymicon ten grondslag ligt komt als A r a en A r o , en in
samengestelde vormen als de mansnamen A r a f r i d en A r a g i s ,
en de vrouwennamen A r o h i l d i s en A r o l i n d a in oude
geschriften voor. Ook leefde hij nog, als A r e , bij de Friezen in de
jaren 1500. A r e m a , oudtijds A e r m a geschreven, is nog heden
een Friesche maagschapsnaam, even als het patronymicon in den
Sassischen vorm A r i n k nog elders in de Nederlanden als
geslachtsnaam bestaat.

Zoo het al twijfelachtig is, bij gemis aan bescheiden, of de

bovengenoemde verfranschte naam A u d r e s e l l e s wel werkelijk
O u d e r z e l e zij, bij eenen anderen verfranschten naam, die
eveneens als eerste lid dit Audre heeft, is het wel zeker, dat
oorspronkelijk het Dietsche woord oud, verbogen tot ouder, oudtijds,
en nog heden in sommige onzer oostelijke gouwspraken ald, alder,
aan den hedendaagschen verfranschten vorm ten grondslag ligt.
Namelijk bij den naam van A u d r u i c q , een stedeke, de
hoofdplaats van het Land van Bredenaerde, eene bijzondere gouw
van Artesië. Deze naam is anders niet als O u d e r w ij k , in goed
Nederlandsch: ter ouder Wijk. In eene oorkonde van de 12de eeuw
komt deze naam voor als A l d e r W i c k , en in latere eeuwen vindt
men hem geschreven als A u d e r w i c k en O u d e r w i c k . De vorm
aud voor oud, ook in België niet onbekend, komt nog voor in de
Artesische plaatsnamen A u d e l a n d , een gehucht bij Licques;
A u d r e h e m , enz.

Het woord hof, in verbogen vorm hove, komt niet zeldzaam in

Artesische plaatsnamen voor. P o l i n c o v e is de verbasterde naam
van een dorp. In goed Nederlandsch zoude men P o l i n k h o v e
moeten schrijven; dat is, het hof (in den locativus ten hove) der
Polinks of Polingen, der afstammelingen van den man [115]die P o l e
heette. Deze was waarschijnlijk een Sas, te oordeelen naar den
vorm van het patronymicon, ink. Dit zelfde patronymicon leeft nog, in
den Frieschen vorm, als P o h l e n g a , de naam van eene
Oostfriesche maagschap. Verder vinden wij het woord hof nog in de
namen van eenige landhoeven of hofsteden en gehuchten in Artesië.
Bij voorbeeld: W e s t h o v e bij Blendecques (Blendekens of
Blindekens, als in West-Vlaanderen?); W e s t e r h o v e bij
Eperlecques; Z u t h o v e (Zuidhove) bij Boisdinghem;
M o n c k h o v e (de hoeve der monniken), O p h o v e , enz. Alle deze
zuiver Dietsche namen bestaan in gouwen, waar thans geen woord
Dietsch meer gesproken wordt, en waar men dus ook deze namen
niet meer verstaat. Geen wonder dan ook, dat men ze niet meer kan
schrijven, en dat men ze langzamerhand verfranscht, verbasterd.
Zoo is de naam der hoeve O p h o v e in deze eeuw reeds
verbasterd tot „A u P a u v r e ”. Daar zal in de volgende eeuw
misschien een Franschman zijn, die naspoort, hoe deze hofstede
aan zulken vreemden naam, „Aan den Arme” gekomen zij. Waarlijk,
van de namen, zoo wel als van de boeken, mag het oude gezegde
gelden: habent sua fata.

Eene andere verbastering van het woord hove kan men aantoonen
bij den naam van het Artesische dorp O f f e k e r q u e , eene
verbastering die lichtelijk op een dwaalspoor, ter naamsverklaring,
leiden kan. Immers het ligt voor de hand om dezen naam te duiden
als O f f e k e r k e , de kerk (ter kerke in den locativus) van O f f e , van
den man die O f f e heette. O f f e toch (O f f o , O f f a , U f f o ) is
een Oud-Germaansche mansnaam, die nog heden bij de Friezen als
zoodanig in volle gebruik is, en al mede oorsprong gegeven heeft
aan de Friesche geslachtsnamen O f f i n g a , O f f e m a , O f f e s ,
O f f e n , O f k e s , enz. en aan de plaatsnamen O f f i n g a w i e r ,
een dorp in Friesland; O f f e n w a r d e n , een dorp bij Bremen
(Duitschland); O f f i g n i e s (dat is oorspronkelijk het patronymicon
O f f i n g e n ), een dorp in Picardië (Frankrijk); O f f a ’ s D y k e , een
oude grenswal in Engeland, in de 8ste eeuw opgericht door O f f a
den Angel-Sassischen koning van Mercia; enz. Intusschen, het
Artesische O f f e k e r q u e heeft met dezen ouden mansnaam niets
te maken. Deze plaatsnaam is oorspronkelijk H o v e k e r k e (ter
kerke bij den hove), zoo als hij nog in oude geschriften voorkomt. In
eene oorkonde [116]van den jare 1100 heet deze plaats eenvoudig
H o v e ; misschien was daar toenmaals nog geen kerk aanwezig.

Ook nog andere plaatsnamen met kerke samengesteld, komen in

Artesië voor: O s t k e r k e , N o r d k e r k e , Z u t k e r k e , S t -
M a r i e - k e r k e , die ook wel gelijk D u n k e r q u e en
O f f e k e r q u e , geschreven worden: O s t k e r q u e , enz. Twee
andere dorpen aldaar hebben hunne namen heden ten dage
volkomen verfranscht, als Vieille-Eglise en Nouvelle-Eglise. Maar op
oude landkaarten, zelfs nog uit de vorige eeuw, heeten ze
O u d e r k e r c k e en N i e u w e r k e r c k e . Laatstgenoemde plaats
vinden wij in oorkonden van de 12de eeuw als: N i u k e r k a en
Niwkerka.
Artesië is, vooral in hare zuidelijke helft, eene schoone landstreek,
met zacht glooiende heuvels en liefelijke dalen, met schoone
bosschen en heldere bronnen en beken. Deze eigenheden van den
bodem worden ook in de namen der plaatsen aangeduid. De
heuvels heeten bergen—naardien het woord berg bij alle volken van
het berglooze Neder-Germanië (onze Nederlandsche gewesten,
Noord en Zuid, en die in Frankrijk daarbij inbegrepen) in gebruik is
voor de heuvels en de kleine, soms haast onmerkbare verheffingen
des bodems. Zulke bergnamen als plaatsnamen, zijn
Boulemberg, Colemberg, Brunemberg, Reberg,
F a u q u e m b e r g u e (dit is V a l k e n b e r g e ), enz. Verder heet
een heuvel bij het dorp Tilques: B l a c k e n b e r g . Die bij Journy
gelegen is, komt in oude oorkonden voor als C a l e n b e r g , die bij
Tournehem als V i e r b e r g , en die bij Moulle, ofschoon thans tot
Hautmont verfranscht, komt in een stuk van de 15de eeuw voor als
de H o b e r c h (hooge berg). Aan den naam van het dorp
B r u n e m b e r g bovengenoemd, ligt ongetwijfeld de oud- en
algemeen-Germaansche, zeer bekende mansnaam B r u n o ten
grondslag, naardien Lambert van Ardres, een Artesische schrijver
uit de 12de eeuw, dezen naam als B r u n e s b e r g h (de berg van
B r u n e , B r u n o of B r u i n ) vermeldt.

De dorpsnaam C o l e n b e r g of C o l e m b e r g wordt heden ten

dage door de Franschen ook wel als Colembert misschreven. In
oude oorkonden vindt men wel C o l e b e r g , en [117]Lambert van
Ardres bovengenoemd verlatijnscht dezen naam tot
C o l s b e r g i u m . Of de mansnaam C o l e , op bladzijde 112
hiervoren vermeld, de oorsprong aan dezen plaatsnaam gegeven
hebbe, dan wel Sint-Nicolaas, of iemand of iets anders, moet ik in
het midden laten.

Aan den voet der heuvels of bergen strekken de dalen zich uit; en
zoo zoekt men ook, nevens de bergnamen, onder de Artesische
plaatsnamen de dalnamen niet te vergeefs. Deze namen zijn zoo
wel eigen aan de werkelijke dalen zelven, als aan de dorpen,
gehuchten, landhoeven, in die dalen gelegen. Op zich zelven,
zonder bijvoegsel, is het woord dal, als naam, eigen aan D a l l e ,
een gehucht bij Lacre. Met bijvoegsels vinden wij de plaatsnamen
W a t e r d a l , gehucht bij Seninghem; B r a m e n d a l , bij
Boisdinghem; L a n g h e n d a l e ; D i e p e n d a l , geh. bij
Boucquehault. Verder B r u c k d a l , gehucht bij Hesdin-l’Abbé;
G r i s e n d a l e , eene landhoeve bij Wimille; M e r l i n g d a l , hoeve,
bij Verlincthun; P i t t e n d a l , To t e n d a l , W y s q u e d a l ,
K i n e n d a l e , enz. De vier eerstgenoemden van deze dalnamen
zijn nog geheel oorbeeldig Dietsch, en in hunne beteekenis
volkomen duidelijk voor iederen Nederlander. In B r u c k d a l
herkennen wij het woord bruck, broek, moeras, dat ook in den naam
Brussel (oorspronkelijk B r o e k z e l e ) voorkomt; in P i t t e n d a l het
woord put, dat ook in West-Vlaanderen en elders in dezen
bijzonderen vorm wordt uitgesproken. Aan den naam M e r l i n g d a l
ligt een patronymicon ten grondslag.

Aan de hellingen der heuvels en bergen ontspringen bronnen, en het

water van die bronnen vloeit als beken door de dalen. Verschillende
plaatsen in Artesië zijn naar die bronnen en beken genoemd. Het
algemeen Dietsche woord bron komt even menigvuldig voor als
born; Hoogduitsch Brunnen en Born; Engelsch burn, born (in de
plaatsnamen B l a c k b u r n , T y b u r n , O s b o r n e ,
H a c h b o r n ) en bourne (B o u r n e m o u t h , A s h b o u r n e ,
I s b o u r n e , E a s t b o u r n e ). In Noord-Nederland als born, borne,
boorn, in de plaatsnamen B o r n , B o r n e , W a r n s b o r n ,
B o a r n w e r t (B o r n w e r d ), B o a r n (B o o r n ), A l d e b o a r n
(O l d e b o o r n ), E a s t e r b o a r n (O o s t e r b o o r n ),
B o a r n s w e a c h (B o o r n z w a a g ), enz. Zoo wisselt ook dit
woord in beide vormen af, in de Artesische plaatsnamen. Een
gehucht [118]bij Licques heet heden ten dage C o u r t e b o u r n e ,
maar wordt in de middeleeuwsche oorkonden als C u r t e b r o n a en
C u r t e b r u n e vermeld. De naam van een ander gehucht, bij
Audrehem, wordt hedendaags als C o u s e b o u r n e geschreven,
maar oudtijds C u s e b r o n a , dat is: Kuischebron, of born van rein,
helder water. Half verfranscht is tegenwoordig de naam
B e l l e b r u n e , alsof het de schoone bron beteekende. Maar in de
12de eeuw werd deze naam door den geschiedschrijver Lambert
van Ardres vermeld als B e r e b r o n a (de bron van den b e r of
b e e r , den edelman of baron?). Nog vroeger, in de 9de eeuw, droeg
deze zelfde bron den naam van H e l i c h b r u n a , de heilige bron.
Een openbare bornput te Wimille heet L o s e n b r u n e , en een
andere bij Tingry L i e n b r u n e , de Liên- of Liedenbron, de bron
voor alle liên, voor iedereen. Dus als tegenhanger of weêrga van de
bovengenoemde B e r e b r o n ? Dit zelfde woord komt ook voor in
den naam L i e n s t r a t e , openbare straat of weg, zooals in de 17de
eeuw nog eene buurt heette in het stedeke Ouderwijk of Audruicq.
Bij Vieux-Moutier, eene plaats die in eene middeleeuwsche
oorkonde O u d e m o n s t r e heet, is eene R o u s q u e b r u n e
bekend, oudtijds ook als R u s c h e b r u n e geschreven; dat is: de
ruischende bron, waarvan het water, bij het afvloeien, een ruischend,
klaterend gerucht maakt.

E s t i e n b e c q (overeenkomende met S t e e n b e k e in Fransch-

Vlaanderen en met S t e e n b e e k bij Zetten in Gelderland) en
M o r b e c q u e (oorspronkelijk de zelfde naam als M o e r b e k e in
Fransch-Vlaanderen, dat ook wel tot M o r b e c q u e wordt
verwaalscht, met M o e r b e k e in ’t Land van Waas, Oost-
Vlaanderen, en met M o e r b e e k , gehucht bij Niedorp in Noord-
Holland) zijn twee Artesische plaatsnamen, waar het woord beek in
voorkomt. Eene straat in de stad Sint-Omaars, hedendaags Rue de
l’Arbalête geheeten, werd in de middeleeuwen B e c q u e s t r a e t
(Beekstraat) genoemd.
Nevens al de bovengenoemde plaatsnamen, die allen samenhangen
met algemeen aardrijkskundige woorden, zijn daar in Artesië nog
vele plaatsnamen, die elk voor zich meer op zich zelven staan. Uit
het groote aantal dezer namen, allen ook zuiver Dietsch van
oorsprong en beteekenis, allen ook zeer bijzonder en zeer
merkwaardig, en tevens in hunne hedendaagsche geijkte
[119]spelling min of meer verfranscht, kunnen wij hier ook slechts
eenige weinigen den Lezer van dit opstel nader voorstellen. Als voor
de hand opgenomen vermeld ik dan, vooreerst: S a n g a t t e , en
W i s s a n t . Dat deze namen werkelijk in goed Nederlandsch, in
algemeen Dietsch, Z a n d g a t en W i t z a n d zijn, namen geheel
eigenaardig aan plaatsen die aan zee en in het witte duinzand
gelegen zijn, bewijst ons Lambert van Ardres. Deze
middeneeuwsche Artesische geschiedschrijver, reeds meermalen in
deze verhandeling genoemd, schrijft (in Latijn) dat de hooge,
onstuimige zee oudtijds een gat zich had gebaand dwars door de
zandduinen, ter plaatse waar later het dorp S a n g a t t e verrees en
dat de bevolking dieshalve aan die plaats den naam van Arenae
foramen gegeven had. En van het dorp W i s s a n t , dat heden ten
dage, nog meer verbasterd, ook wel als W i s s a n geschreven
wordt, schrijft hij: „Ab albedine arenae vulgari nomine appellatur
Witsant.”

Verder M a r c q (mark of grens), O y e , hedendaags door de

Franschen ten onrechte uitgesproken als hun woord oie, gans (’t is
echter ode of eenzame onbewoonde plaats); W i e r e (Friesch wier
of vluchtheuvel?); l e W a t (wad of doorwaadbare plaats in
waterstroom of beek); W i m i l l e (windmolen), en vele anderen zijn
eveneens zulke bijzondere namen.
Al de plaatsnamen, tot dusverre in deze verhandeling genoemd en
verklaard, zijn eigen aan plaatsen die nog heden ten dage bestaan,
en komen in bovenvermelde, zoowel verbasterde als zuiver Dietsche
vormen, in de hedendaags geldige Fransche taal voor. Deze namen
zijn bij honderdtallen te tellen. Wil men echter in grondboeken en in
oude geschriften, in middeleeuwsche oorkonden, vooral in oude
koopbrieven gaan zoeken, dan vindt men de Dietsche namen van
velden en wegen, van huizen en straten in Oud-Artesië bij
duizendtallen. Ook onder dat zeer groote aantal Oud-Dietsche
namen van dat gewest, die in den loop der eeuwen door den
overheerschenden Franschen invloed zijn verloren gegaan, en die
den hedendaagschen ingezetenen volkomen onbekend zijn, komen
er zeer velen voor die uit een taalkundig oogpunt allermerkwaardigst
zijn, en die ten volsten de aandacht, de opsporing en onderzoeking
der Germaansche [120]taalgeleerden van onzen tijd verdienen. Hoe
gaarne zoude ik dezen schat van oude namen den Lezer nader
ontsluiten, ten volle kenbaar maken. Een geheel boekdeel zoude ik
daarmede kunnen vullen, en—slechts weinige bladzijden hier staan
mij daar voor ten dienste. Zoo moet ik mij tot enkele tientallen van
deze oude namen beperken.

Namen van stukken land, velden, akkers, enz. B r i e d s t i c ,

G r o t s t i c , L a n g s t i c , C r o m s t i c (Breed-, Groot-, Lang-,
Kromstuk), H a n g s t i c (aan de helling van eenen heuvel),
S k e r m e s t i c , V i e r h o r n s t i c en D r i e h o r n s t i c (het stuk
met vier en dat met drie hoeken of hoornen; nog heden is het woord
hoek in ’t Friesch horn of hoarne, en is daar een stuk land te Marsum
in Friesland, dat de T r y e - h o a r n e - f i n n e , de Driehornfenne,
heet). Verder S t r i d l a n d , G e n d e k i n s l a n t (G e n d e k i n is
een mansnaam, in verkleinvorm), M o r l a n t , R o d e l a n t ,
Ta r w e l a n t , B r u n e v e l t , S t i e n v e l t en S a n c t i n g e v e l t
(Sint-Inge-veld? aan den weg van Gisen (Guines) naar Witzand
(W i s s a n t ), heden ten dage tot Saint-Inglevert verfranscht),
S t r i d a k e r, G o m e n a c r e , H o b b e n a k e r, B l e k e n a k e r,
N a n t a c r e , A l v e s m e r s c e n e (Alvesmeerschen; A l f is een
Oud-Germaansche mansnaam), B o n e m e r s e n e , enz.

Namen van bosschen en hout. C o r t e b o s c , M a f f e r b o s c ,

B o c h o u t en B o c h o l t (Beukenhout of bosch; deze naam
bestaat heden nog en is nu tot Boucquehault verfranscht), E k h o u t
(Eekhout, Eikenbosch), M a l s h o u t , S c a p s h o u t ,
Mutshout, Lantershout.

Namen van straten en wegen, dijken, putten, huizen, bruggen.

H o s t r a e t , H o s t r a t , O s t r a e t (Hoogstraat, zeer algemeen in
schier al de steden en dorpen van Oud-Artesië, even als de
Highstreet is in de Engelsche plaatsen). H a g h e s t r a e t ,
Stienstraet, Witestraet, Weststraet, Weetstraet,
W a g h e s t r a e t ; in de stad Sint-Omaars: A r k e s t r a e t (Rue
d’Arques—Arques is een naburig dorp—, hedendaags Rue d’Arras
genoemd), B e c q u e s t r a e t , zie bladzijde 118, P o t e s t r a e t —
Rue du Pot—, W a c k e s t r a e t , V i n c q u e s t r a e t , enz.
M e l l e w o g , O u d e w o g en O u d e w o g h e , S c a l r e w o g e ,
de weg naar S c a l l e , hedendaags tot Escalles verfranscht;
G i s e n e w o g , P a p e n w o g e , H e r e w o g ; K o l d i c [121]
(K o l d y k is ook de naam van eene sate of landhoeve bij den dorpe
Grouw in Friesland, en deze naam komt bij de hedendaagsche
Friezen ook nog veelvuldig als geslachtsnaam voor), S c a r d i c
(Schaardijk; S c h a r e n d ij k e is de naam van een dorp op het
eiland Schouwen in Zeeland). C a l k p i t , M a r l e p i t . Pit in plaats
van put is nog hedendaags Westvlaamsch. W o l h u s , W i n t h u s .
Het raadhuis van het stadje Ouderwijk (A u d r u i c q ) heette voor
twee eeuwen nog l e L a n d s h u s , Landshuis, omdat het niet enkel
voor Ouderwijk diende, maar tevens voor het geheele Land van
Breedenaerde, eene kleine gouw in Artesië, waar van dit stedeke
middenpunt en hoofdplaats was. En zoo ook heette het raadhuis van
het Land van den Hoeke, eene andere kleine gouw in dit gewest,
G y s e l h u s .—L e n e b r i g g e . Het dorp H o o g b r u g g e bij Sint-
Omaars heet tegenwoordig Hautpont, maar komt in de geschriften
uit vorige eeuwen als H o b r i g g e voor, en de ingezetenen van dat
dorp als H o b r i g h e n a r d s , Hoogbruggenaren in onze
hedendaagsche taal en spelling. Twee bruggen te, of bij Sint-
Omaars heeten in oorkonden van de 14de en 15de eeuw: L o b r i g h e
en Te x b r i g h e .

Nog enkele Oud-Dietsche namen, uit middeleeuwsche oorkonden

verzameld en allen aan plaatsen in Artesië eigen, mogen hier ten
slotte een plaatsken vinden: H e l d e , S t a p e l e , S t r i p e ,
W i t s t i e n , W a l r i c h o v e (hof van W a l r i k , Germaansche
mansnaam), H o n g e r c o u t r e , B o f f e r s h i l , W o l f h a m ,
Bontun, Riede, Knol, Brocshole, Doetlage,
S t i e n r o k k e s (Steenrots), R a v e n s t i e n e , R o b a r s d a l ,
W a l l e s h o u c k (W a l l e is een mansnaam), H a s e w i n k e l ,
R a m b r e c t e s g a t (van Rambert, Ravenbrecht, volledige oude
mansnaam), enz.

Als aanhangsel noemen wij hier nog de namen van sommige

Artesische wateren, en wel eerstelijk den naam van het riviertje, dat
langs de stad St. Omaars vloeiende, de grensscheiding vormt
tusschen Artesië en Fransch-Vlaanderen, en dat de A a heet. Geen
oorbeeldiger Dietsche waternaam is er bekend, dan juist deze naam
A a , die eigen is aan riviertjes, stroomkes, beken, schier zonder tal,
in alle landen, gewesten en gouwen van geheel Neder-Germanië,
van Artesië langs de kusten van Noord- en Oostzee tot in de
Oostzee-gewesten van Rusland toe. Deze naam, in de Friesche
gewesten als E e of I e en Y e , Y voorkomende, [122]beteekent
eenvoudig water, stroomend water. Een water bij het stedeke
Ouderwijk (A u d r u i c q ), waarschijnlijk eene gegravene vaart,
heette nog in de 17de eeuw S t a v a r t , (S t a ( d e ) , oever? ook