BRING YOUR OWN ARCHITECTURESOFTWARE ARCHITECTURE BECOMES -> IS A DEVELOPER SKILL

GDGDÜSSELDO

RF

08.12.2016

GERNOT SCHULMEISTERLives in MönchengladbachDevelopes websites with TYPO3 and AngularWorks for TeamWFP Has a migration background and comes from Southeast-Europe (Austria)Likes operative CMS evaluations, Data science, Software Architecture, Meetups, Bar camps

facebook.com/gernot.schulmeistertwitter.com/mistakanista1

SEITE 2

SCHEDULE

Motivation Definition Macro / Micro architecture Tasks of an architect Process of development Design principles Architecture style -> Domain driven

design

MOTIVATION

Your architecture is only good as long as you did not tell one about it

Architecture should be developed in a team I like to read about architecture I like to go to architecture meetups But architecture is only theory until you apply it

SEITE 4

The fundamental organization of a software system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution

DEFINITION

MACROARCHITECTURE

Standardization, frame for everyone Developer can easy switch between teams Concentration on the application specifics Avoidance of errors in critical areas by proved

concepts Lower costs by fewer products, licences and trainings

for specialists Reuse of solutions ideas across domains

SEITE 6

MICROARCHITECTURE

Space for individual solutions Optimal solutions for specific problems New trends can be adapted quickly Wrong decisions have not so much impact Lower dependencies to individual suppliers

SEITE 7

CANDIDATES FOR OVERLAPPING TOPICS

SEITE 8

EXAMPLE USER INTERFACE

SEITE 9

PROCESS OF ARCHITECTURE DEVELOPMENT

SEITE 10

ARCHITECTURE TASKS

Construct, design and implement Evaluate, decide and consult Grant the fulfillment of requirements Document Communicate and are diplomats and acrobats Simplify Make assumptions and preconditions explicit Need courage

SEITE 11

ARCHITECTURE DEVELOPMENT

SEITE 12

DESIGN PRINCIPLES

SEITE 13

HEURISTICS

Mix top-down, bottom-up & outside in strategies hierarchical composition & decomposition

Loose coupling (number of relations of a block), high cohesion (put together what belongs together)

Don´t repeat yourself vs no shared code Lego thinking Expect changes & switch the perspective Expect errors and failures (failure first) Regular refactoring & redesign Anti-tenacity Simple: CUTE instead of KISS

SEITE 14

CUTE

Comprehensive: regarding the business domain, avoid technical constructs, focus on intention and not on implementation

Unidimensional: low complexity, linear reading, avoid nesting and loops Terse: short and compact, few code is quicker to read and understand Elegant: in mathematical sense, nice to read

SEITE 15

SOLID FOR ARCHITECTURE

SRP - Single responsibility principle ( separation of concerns, encapsulation, information hiding)

OCP - Open close principle (open for extensions, closed for modifications)

LSP - Liskov substitution principle (a base class should be always substituteable by its subclasses)

ISP - Interface segregation principle (the user should be offered an interface which only fulfills his tasks, small interfaces)

DIP - Dependency inversion principle (dependency only from concrete to abstract classes, so that the concrete ones can easily be replaced and decoupled)

SEITE 16

ARCHITECTURE STYLES

SEITE 17

DOMAIN DRIVEN DESIGN

SEITE 18

BOUNDED CONTEXT

Central idea of strategic design to find a fitting granularity for a domain

The application business logic consists of several bounded context

Example Google dev fest: Registration of applicants Print of the the badges for the visitors Capacity planning for food and sessions

SEITE 19

CONTEXT MAP

Describes the dependencies between the bounded contexts Propagates the models from one context to the next Shared kernel (share parts of the model) Customer/supplier (customer has veto for supplier changes of the model) Conformist (customer follows changes of the supplier model) Anticorruption layer (local model translates foreign model) Open / host service (SOA interfaces are offered to the public) Published language (ubiquitous domain language for the team members for

communication)

SEITE 20

CONCLUSION

Every developer is also an architect in his responsibility area The awareness of the importance of architecture increased Architecture skills are not necessarily connected with a social uprise

anymore Lego thinking

SEITE 21