Skip to main content

Microservices Design Patterns



functional decomposition or domain-driven design
well-defined interfaces 
explicitly published interface 
single responsibility principle
potentially polyglot


http://blog.arungupta.me/microservice-design-patterns/
http://blog.arungupta.me/microservices-monoliths-noops/
https://go.forrester.com/blogs/13-11-20-mobile_needs_a_four_tier_engagement_platform/
three-tier architecture — presentation, application, data
vs.
4 tier -- client, delivery, aggregation, services

Comments

Post a Comment

Popular posts from this blog

Banana Monkey Jungle

Why functional over OO? https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 Inheritance Banana Monkey Jungle The diamond relationship Fragile parent class Categorical (Taxonomy) v.  Containment (or Exclusive Ownership) Hierarchies Encapsulation Object passed by reference to an Object Constructor is not safe Deep cloning MC Hammer v.   Immutability Global Scope Polymorphism https://www.cs.utexas.edu/~mitra/csSummer2013/cs312/lectures/interfaces.html Design by Behavior not Data

Build software like you build houses

Interfaces facilitate visibility. Software is the only engineering practice that doesn't allow runtime visibility to end-user. If this were true for construction, it would mean your builder would have to live with you for you to even guess what the problem is. https://vimeo.com/221049715 https://github.com/stripe/veneur