Your microserviceas a Function

Phil CalçadoSoundCloud

> 11 hours of audio uploaded every minute

~ 300 million people every month

for this talk:implementation: code

design: how you abstract concepts in your system

architecture: how systems talk to each other

how I got started with object-oriented programming

,Q�DQ\�FDVH��ZRUNLQJ�WKH�&217(;7�0$3�LQWR�GLVFXVVLRQV�LV�HVVHQWLDO�LI�WKH�QDPHV�DUH�WR�HQWHU�WKH8%,48,7286�/$1*8$*(��'RQW�VD\��ಯ*HRUJHV�WHDPV�VWXII�LV�FKDQJLQJ��VR�ZHUH�JRLQJ�WR�KDYHWR�FKDQJH�RXU�VWXII�WKDW�WDONV�WR�LW�ರ�6D\�LQVWHDG��ಯ7KH�7UDQVSRUW�1HWZRUN�PRGHO�LV�FKDQJLQJ��VR�ZHUHJRLQJ�WR�KDYH�WR�FKDQJH�WKH�WUDQVODWRU�IRU�WKH�%RRNLQJ�FRQWH[W�ರ

Relationships Between BOUNDED CONTEXTS7KH�IROORZLQJ�SDWWHUQV�FRYHU�D�UDQJH�RI�VWUDWHJLHV�IRU�UHODWLQJ�WZR�PRGHOV�WKDW�FDQ�EH�FRPSRVHG�WRHQFRPSDVV�DQ�HQWLUH�HQWHUSULVH��7KHVH�SDWWHUQV�VHUYH�WKH�GXDO�SXUSRVH�RI�SURYLGLQJ�WDUJHWV� IRUVXFFHVVIXOO\�RUJDQL]LQJ�GHYHORSPHQW�ZRUN��DQG�VXSSO\LQJ�YRFDEXODU\� IRU�GHVFULELQJ� WKH�H[LVWLQJRUJDQL]DWLRQ�$Q�H[LVWLQJ�UHODWLRQVKLS�PD\��E\�FKDQFH�RU�E\�GHVLJQ��IDOO�QHDU�RQH�RI�WKHVH�SDWWHUQV��LQ�ZKLFK�FDVH\RX�FDQ�GHVFULEH�LW�XVLQJ�WKDW�WHUP��YDULDWLRQV�GXO\�QRWHG��7KHQ��ZLWK�HDFK�VPDOO�GHVLJQ�FKDQJH��WKHUHODWLRQVKLS�FDQ�EH�GUDZQ�FORVHU�WR�WKH�FKRVHQ�SDWWHUQ�2Q�WKH�RWKHU�KDQG��\RX�PD\�ILQG�WKDW�DQ�H[LVWLQJ�UHODWLRQVKLS�LV�PXGGOHG�RU�RYHUFRPSOLFDWHG��6RPHUHRUJDQL]DWLRQ�PLJKW�EH�QHFHVVDU\�MXVW�WR�PDNH�DQ�XQDPELJXRXV�&217(;7�0$3�SRVVLEOH��,Q�WKLVVLWXDWLRQ��RU�DQ\�VLWXDWLRQ� LQ�ZKLFK�\RX�DUH�FRQVLGHULQJ�UHRUJDQL]DWLRQ�� WKHVH�SDWWHUQV�SUHVHQW�DUDQJH�RI�FKRLFHV�WKDW�DUH�IDYRUHG�LQ�GLIIHUHQW�FLUFXPVWDQFHV��3URPLQHQW�YDULDEOHV�LQFOXGH�WKH�OHYHORI�FRQWURO�\RX�KDYH�RYHU�WKH�RWKHU�PRGHO��WKH�OHYHO�DQG�W\SH�RI�FRRSHUDWLRQ�EHWZHHQ�WHDPV��DQG�WKHGHJUHH�RI�LQWHJUDWLRQ�RI�IHDWXUHV�DQG�GDWD�7KH�IROORZLQJ�VHW�RI�SDWWHUQV�FRYHUV�VRPH�RI�WKH�PRVW�FRPPRQ�DQG�LPSRUWDQW�FDVHV��ZKLFK�VKRXOGJLYH�\RX�D�JRRG�LGHD�RI�KRZ�WR�DSSURDFK�RWKHU�FDVHV��$�FUDFN�WHDP�ZRUNLQJ�FORVHO\�RQ�D�WLJKWO\LQWHJUDWHG�SURGXFW�FDQ�GHSOR\�D�ODUJH�XQLILHG�PRGHO��7KH�QHHG�WR�VHUYH�GLIIHUHQW�XVHU�FRPPXQLWLHVRU�D�OLPLWDWLRQ�RQ�WKH�FRRUGLQDWLRQ�DELOLWLHV�RI�WKH�WHDP�PLJKW�OHDG�WR�D�6+$5('�.(51(/�RU�&86�720(5�6833/,(5�UHODWLRQVKLSV��6RPHWLPHV�D�JRRG�KDUG�ORRN�DW�WKH�UHTXLUHPHQWV�UHYHDOV�WKDWLQWHJUDWLRQ�LV�QRW�HVVHQWLDO�DQG�LW�LV�EHVW�IRU�V\VWHPV�WR�JR�WKHLU�6(3$5$7(�:$<6��$QG��RI�FRXUVH�PRVW�SURMHFWV�KDYH�WR�LQWHJUDWH�WR�VRPH�GHJUHH�ZLWK�OHJDF\�DQG�H[WHUQDO�V\VWHPV��ZKLFK�FDQ�OHDGWR�23(1�+267�6(59,&(6�RU�$17,&255837,21�/$<(56�

Shared Kernel

0DLQWDLQLQJ�0RGHO�,QWHJULW\ ���

Domain-Driven Design: Tackling Complexity in the Heart of Software. Domain-Driven Design: Tackling Complexity in the Heart of Software, ISBN: 0-321-12521-5Prepared for pcalcado@gmail.com, Phillip CalçadoCopyright © 2004 by Eric Evans. This PDF is made available for personal use only during the relevant subscription term, subject to the Safari Terms of Service. Any other use requires priorwritten consent from the copyright owner. Unauthorized use, reproduction and/or distribution are strictly prohibited and violate applicable laws. All rights reserved.

Gzs%

ef . .

. . . . .

, .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. ,

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

Permission

to copy

without fee

all or

part of

this materinl

is granted

prowded that

the topics

are not

mada or distributed

for direct

comm

crciol advantage,

the ACM

copyright notice

ond tho

lillc of

the publication

and its

dare appear.

and notice

is given

that copying

is by perm

ission of

the Association

for Com

puting Machinery.

To copy

othcrwisc, or

to republish.

requires B fee

and/or specific

pornlission. HOPL-11/4/93/M

A,USA o 1993

ACM 0-89791.571.2/93/0004/0069...$1.50

:LJ 2 2

.x E

.m

8 al

:5 a

.6

69 ACM

SIGPLAN Notices, Volum

e 28, No. 3 M

arch 1993

😧😆😄😃😀😧

how I got started with functional programming

Gzs%

ef . .

. . . . .

, .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. ,

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

Permission

to copy

without fee

all or

part of

this materinl

is granted

prowded that

the topics

are not

mada or distributed

for direct

comm

crciol advantage,

the ACM

copyright notice

ond tho

lillc of

the publication

and its

dare appear.

and notice

is given

that copying

is by perm

ission of

the Association

for Com

puting Machinery.

To copy

othcrwisc, or

to republish.

requires B fee

and/or specific

pornlission. HOPL-11/4/93/M

A,USA o 1993

ACM 0-89791.571.2/93/0004/0069...$1.50

:LJ 2 2

.x E

.m

8 al

:5 a

.6

69 ACM

SIGPLAN Notices, Volum

e 28, No. 3 M

arch 1993

Programming R. Morr is Techniques Edi tor

On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University

This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom- positions are discussed. The unconventional decomposi- tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.

Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design

CR Categories: 4.0

Introduction

A lucid s tatement o f the phi losophy of modula r p rogramming can be found in a 1970 tex tbook on the design of system programs by Gouth ie r and Pon t [1, ¶I0.23], which we quote below: 1

A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching.

Usual ly nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means o f examples, suggest some criteria which can be used in decompos ing a system into modules.

Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part

of this material is granted, provided that reference is made to this publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Com- puting Machinery.

Author's address: Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213.

1053

A Brief Status Report

The ma jo r advancement in the area o f modula r p rogramming has been the development o f coding techniques and assemblers which (l) allow one module to be written with little knowledge o f the code in another module, and (2) allow modules to be reas- sembled and replaced wi thout reassembly o f the whole system. This facility is extremely valuable for the product ion o f large pieces o f code, but the systems mos t often used as examples o f problem systems are highly- modular ized programs and make use o f the techniques ment ioned above.

1 Reprinted by permission of Prentice-Hall, Englewood Cliffs, N.J.

Communications December 1972 of Volume 15 the ACM Number 12

CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 1

1 IntroductionThe fundamental purpose of a type system is to prevent the occurrence of execution errors dur-ing the running of a program. This informal statement motivates the study of type systems, butrequires clarification. Its accuracy depends, first of all, on the rather subtle issue of what consti-tutes an execution error, which we will discuss in detail. Even when that is settled, the absenceof execution errors is a nontrivial property. When such a property holds for all of the programruns that can be expressed within a programming language, we say that the language is typesound. It turns out that a fair amount of careful analysis is required to avoid false and embar-rassing claims of type soundness for programming languages. As a consequence, the classifica-tion, description, and study of type systems has emerged as a formal discipline.

The formalization of type systems requires the development of precise notations and defi-nitions, and the detailed proof of formal properties that give confidence in the appropriatenessof the definitions. Sometimes the discipline becomes rather abstract. One should always remem-ber, though, that the basic motivation is pragmatic: the abstractions have arisen out of necessityand can usually be related directly to concrete intuitions. Moreover, formal techniques need notbe applied in full in order to be useful and influential. A knowledge of the main principles oftype systems can help in avoiding obvious and not so obvious pitfalls, and can inspire regularityand orthogonality in language design.

When properly developed, type systems provide conceptual tools with which to judge theadequacy of important aspects of language definitions. Informal language descriptions often failto specify the type structure of a language in sufficient detail to allow unambiguous implemen-tation. It often happens that different compilers for the same language implement slightly dif-ferent type systems. Moreover, many language definitions have been found to be type unsound,allowing a program to crash even though it is judged acceptable by a typechecker. Ideally, for-mal type systems should be part of the definition of all typed programming languages. This way,typechecking algorithms could be measured unambiguously against precise specifications and,if at all possible and feasible, whole languages could be shown to be type sound.

In this introductory section we present an informal nomenclature for typing, execution er-rors, and related concepts. We discuss the expected properties and benefits of type systems, andwe review how type systems can be formalized. The terminology used in the introduction is notcompletely standard; this is due to the inherent inconsistency of standard terminology arisingfrom various sources. In general, we avoid the words type and typing when referring to run timeconcepts; for example we replace dynamic typing with dynamic checking and avoid commonbut ambiguous terms such as strong typing. The terminology is summarized in the DefiningTerms section.

Type Systems

Luca Cardelli

Microsoft Research

😧😠😐😒😓😧

there isn’t a lot out there on engineering for functional programming

HTTP

HTTP

MySQL

what if we apply function composition?

turns out functional principles correlate with

good implementation

going up one level

life of a request to SoundCloud.com

ActualFeature

Request Validator

User

what if we apply function composition?

basically

basically

ActualFeature

Request Validator

User

Authentication Geo IP Rate Limiting AvailableFeatures

ActualFeature

User

ActualFeature

User

Filters

Service

}

we have heaps of filters

turns out functional principles correlate

with good design

going up one level

metadatatrack

credentialsuser

trackpageplayback groups

facebookintegration

database api …

what if we apply function composition?

you want your services to be stateless as possible

you want to be careful where you store stuff

💽

💽

💽

💽

💽

💽

💽💽

💽

💽

💽

💽💽

💽Filters

}Services

track page

<track <trackmetadata>stats>

<usermetadata>

💽 💽 💽

<contentfiltering>

<monetisation

rules>

turns out functional principles correlate

with good architecture

we still lack material around engineering in

functional languages, but the basic principles already

offer a good framework

tl;dr

small functions + small combinators all

the way up

Q&A