Domain-Oriented Microservice Architecture • Hacker News Board

Re: Domain-Oriented Microservice Architecture

#41

Post by ct520 » Sat, Jul 25, 2020, 4:43 AM UTC

fiddlerwoaroof wrote: post #37

gen220 wrote: post #17

Earlier quoted context omitted.

If you ever have to start a big company from scratch, this is how to do it. There aren’t any major drawbacks to this model when a business is young (first couple years). The downsides appear when you have different parts of your application with very different load requirements. It also takes a lot of discipline to write code this way. Without strict code review and more experienced hands, the bounded contexts fall a…

It mostly hides the damage: instead of a code base no one understands, you have network traffic no one understands.

I’ll take the latter any day with good patterns of aggregating to a grey log. Having to triage production issues in a multiple application saas environment, The latter has always been easier to me. Don’t get me started on trouble shooting someone else’s crazy event queues

Re: Domain-Oriented Microservice Architecture

#42

Post by theptip » Sat, Jul 25, 2020, 4:48 AM UTC

Twisol wrote: post #2

Depending on what angle you come at this from, you could say that DOMA groups services into clusters ("domains"), as Uber has done here, or that services always should have been domain-driven, and DOMA welcomes the networking layer inside the bounded context as well. I've spent a lot of time trying to understand when a microservices architecture makes sense, what the caveats are, and what philosophy one should take t…

As far as I can tell from reading Evans' DDD, there's nothing forbidding network calls inside a service. For a trivial example, you make network calls from your API to your DB. And also to your Redis cache, and then if your service runs async/periodic tasks, to your task queue, say your RMQ & Celery instances.

So to me the OP reads like "we're coming up with some new terminology for a bounded context, and also defining how those contexts should be allowed to layer in order to simplify/control failure modes".

The layering stuff is more interesting than Uber's rediscovering bounded contexts, though it's definitely interesting that they have come into agreement with Evans (and the rest of the DDD community) on the "Service == Bounded Context" principle.

Re: Domain-Oriented Microservice Architecture

#43

Post by sroussey » Sat, Jul 25, 2020, 4:57 AM UTC

Uber thinks they only have that many services? Yikes, double, or triple the number... several years ago. Maybe they have fewer now?

Re: Domain-Oriented Microservice Architecture

#44

Post by javajosh » Sat, Jul 25, 2020, 5:01 AM UTC

systematical wrote: post #39

I'm looking forward to the article about the problems DOMA introduced for them and what they came up with next. Wonder if we will see a full circle back to monoliths. I know I'm being snarky and I have used micro-services myself, but only when it was smacking me in the face as the best tool for the job. Is the fools-gold rush still on to do everything as a micro-service from the get-go? Side note, I can't wait to hea…

>Is the fools-gold rush still on to do everything as a micro-service from the get-go?

Yes.

Re: Domain-Oriented Microservice Architecture

#45

Post by fiddlerwoaroof » Sat, Jul 25, 2020, 5:09 AM UTC

ct520 wrote: post #41

fiddlerwoaroof wrote: post #37

Earlier quoted context omitted.

It mostly hides the damage: instead of a code base no one understands, you have network traffic no one understands.

I’ll take the latter any day with good patterns of aggregating to a grey log. Having to triage production issues in a multiple application saas environment, The latter has always been easier to me. Don’t get me started on trouble shooting someone else’s crazy event queues

This is really interesting to me: I’ve always found dealing with code preferable to dealing with network communication. It might be because the languages I work with (common lisp, Clojure and Scala/Java/Kotlin) all have excellent code navigation abilities.

Re: Domain-Oriented Microservice Architecture

#46

Post by Twisol » Sat, Jul 25, 2020, 5:15 AM UTC

theptip wrote: post #42

Twisol wrote: post #2

Depending on what angle you come at this from, you could say that DOMA groups services into clusters ("domains"), as Uber has done here, or that services always should have been domain-driven, and DOMA welcomes the networking layer inside the bounded context as well. I've spent a lot of time trying to understand when a microservices architecture makes sense, what the caveats are, and what philosophy one should take t…

As far as I can tell from reading Evans' DDD, there's nothing forbidding network calls inside a service. For a trivial example, you make network calls from your API to your DB. And also to your Redis cache, and then if your service runs async/periodic tasks, to your task queue, say your RMQ & Celery instances. So to me the OP reads like "we're coming up with some new terminology for a bounded context, and also defini…

> As far as I can tell from reading Evans' DDD, there's nothing forbidding network calls inside a service.

You're quite right.

> [...] defining how those contexts should be allowed to layer [...]

This, however, seems to go against the spirit of things. There is a consistent "ubiquitous language" within a bounded context, where domain terms are concrete and unambiguous. (Or rather, the context disambiguates the language.) The concept of "layered contexts" seems to neuter the concept. Does each layer successively disambiguate the one above? Or does it add new terms that didn't exist?

The layering here sounds much more technically-motivated than domain-oriented. And my argument is that the networking internal to their "domains" is largely an artifact of having build DOMA out of a plethora of disorganized microservices. Doubtless there will be some necessary networking remaining, as you remarked on, such as between processors and databases. But the origin here suggests most of it is left over from what came before.

Re: Domain-Oriented Microservice Architecture

#47

Post by sgt-serverless » Sat, Jul 25, 2020, 5:20 AM UTC

The last two systems I designed and built where microservices based. One manages 2 million transactions per day, the other is processing millions of dollars worth of transactions a month. While it might be slightly harder to grep microservices, if you do them right, I feel the benefits far outweigh the drawbacks of going monolith. I think the hardest part is trusting that your system can not be digested in just one bottlenecked app standing up. This really goes deeper than microservices as well, into event-driven programming. Too much time seems to be spent on people saying, well my monolith is just fine. It might be, but doing a microservice system works, you just have to be able to ride the wave.

Re: Domain-Oriented Microservice Architecture

#48

Post by staticassertion » Sat, Jul 25, 2020, 5:30 AM UTC

systematical wrote: post #39

I'm looking forward to the article about the problems DOMA introduced for them and what they came up with next. Wonder if we will see a full circle back to monoliths. I know I'm being snarky and I have used micro-services myself, but only when it was smacking me in the face as the best tool for the job. Is the fools-gold rush still on to do everything as a micro-service from the get-go? Side note, I can't wait to hea…

I'm a fool who has done microservices first and is very happy about it. Just want to throw that out there into the sea of negativity I see towards microservices.

Re: Domain-Oriented Microservice Architecture

#49

Post by staticassertion » Sat, Jul 25, 2020, 5:42 AM UTC

sixdimensional wrote: post #40

kopos wrote: post #26

Feels like a lot of old knowledge was discounted / ignored and the mistakes are being rediscovered. Feels a bit like the Hexagonal Architecture being rediscovered. Micro service with half life of 1.5 years? Does that mean that enough planning is not being done? Or leadership failure at software planning level? Collaboration between teams at scale is very hard but that is what the leadership layer is for - to collabor…

Or how about plain old onion architecture... even older than hexagonal. This is literally scaled/distributed domain-driven design (DDD). I have felt strongly that folks got so caught up in the hype of yet another new thing they forgot how to extend what came before. It feels like a reinvention of existing ideas at larger scale, and a pattern we keep repeating. I'm not complaining, of course - new things are possible…

I'm confused. You're saying that people are reinventing existing ideas at larger scale, but you also are saying that people don't know how to extend what came before? Those sound like the same exact thing.

Re: Domain-Oriented Microservice Architecture

#50

Post by rumanator » Sat, Jul 25, 2020, 6:15 AM UTC

systematical wrote: post #39

I'm looking forward to the article about the problems DOMA introduced for them and what they came up with next. Wonder if we will see a full circle back to monoliths. I know I'm being snarky and I have used micro-services myself, but only when it was smacking me in the face as the best tool for the job. Is the fools-gold rush still on to do everything as a micro-service from the get-go? Side note, I can't wait to hea…

> Wonder if we will see a full circle back to monoliths.

For global-scale web applications? Obviously you won't. High-availability, low latency, resilience, scalability, performance. You don't get any of that by running your app on a single box. That ship has sailed two or three decades ago. Physics establishes all the limits, not software architects.

Distributed system critics, where they fixate on trendy microservices architectures or poopoo other suggestions like DOMA, should take a step back and look at themselves and what they are actually complaining about. Yes, a solution with no moving parts is simpler than a solution with some moving parts. But have you really noticed what problems are being solved by adding these pieces?