Modular monoliths by Simon Brown

Подписаться 158 тыс.

Просмотров 18 тыс.

50% 1

If you want evidence that the software development industry is susceptible to fashion, just go and take a look at all of the hype around microservices. It's everywhere! For some people microservices is "the next big thing", whereas for others it's simply a lightweight evolution of the big service-oriented architectures that we saw 10 years ago "done right". Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well structured monolith. And this begs the question that if you can’t build a well-structured monolith, what makes you think microservices is the answer?
Simon Brown is an independent consultant and helps organisations to build better software by adopting a lightweight, pragmatic approach to software architecture. He is the creator of the C4 software architecture model and the author of Software Architecture for Developers - a developer-friendly guide to software architecture, technical leadership and the balance with agility. Simon lives in Jersey (the largest of the Channel Islands) and his client list spans over 20 countries, including organisations ranging from small technology startups through to global household names. He still codes too.
[JGN-0641]

Опубликовано:

7 сен 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 12

@kobac8207 7 лет назад

oh, and the unit tests :) You don't have to mock in order to do unit testing. If collapsing layers doesn't enable you to isolate a "unit" it doesn't mean you can't/shouldn't unit test. Take a look at Gary Bernhardt's talk from 2012 "Boundaries" to see the Imperative shell - Functional core approach

@djgreyjoy1495 10 месяцев назад

People don't get it, even after this wonderful talk. LoL

@tdrake59 6 лет назад

Doing this will avoid cyclical package level dependencies. Typical package dependency graphs look like spaghetti. It would be nice if java provided a means of expressing some level of nested package access (package-parents) such that classes marked as 'package-parents' would be visible to all classes in the same package and in all parent packages but not by 'sibling' or 'cousin' packages. Perhaps it would be good to go a step further and be able to declare the top-level package in which that class is visible. e.g. org.foo.customer.service.dao.Customer.class would be visible to org.foo.customer.service.dao and org.foo.customer.service and org.foo.customer, but NOT visible in org.foo.vendor or org.foo.customer.search

@TheodoreRavindranath 6 лет назад

Package heirarchy would have adressed most of the problems. But, OSGi can offer best of monolith and microservices. But, for some reason it didn't gain momentum!

@TheodoreRavindranath 6 лет назад

Java should have had package heirarchy (parent-child relationship of packages) from day 1. I believe Scala has package heirarchy..

@JanPavlikdr Год назад

Brilliant… but basically is use common sense depends your needs - not just go with blind “rule”. I’m PHP programmer since version 3, and still working with custom stuff without Framework - it’s over complicated in so many cases that I find it much more time consuming.

@kobac8207 7 лет назад

This talk didn't give a solution to the problem that I expected. He's talking about the fact that people are using microservices in order to ensure programmer's discipline and instead showed that you could build modular system in monolith as well, that ensures programmer's discipline by leveraging access modifiers in the programming language we're using. But we're still addressing the consequence rather that the root cause. If you have a team adept at good programming skills and design there're not so many things they will deliberately screw up, so you can build monolith with public packages without the fear. If you have a team that doesn't have good programming and design skills, than there's nothing that can save you from them. No microservices, no access modifiers, no packaging.

@romulus1981 6 лет назад

I think there is a missing link between worker organisation and work organisation. He addressed the work organisation as I see in many of the decomposition methods but who is defining the worker organisation? This is the biggest problem. If teams are structured around domains or aggregates/services in DDD parlance, Conway's law does the rest.

@KangJangkrik 3 года назад

I used to build this with Java: Entity => DAO => Repository => Model => ViewModel => View Then I started to learn another language like Golang and Python. Darn... there is no such thing of complexity :o