5 ms·

>But do you know what helps? Having physical boundaries you can't cross so easily. Rarely have I disagreed with something more strongly :) If a team lacks the

>But do you know what helps? Having physical boundaries you can't cross so easily. Rarely have I disagreed with something more strongly :) If a team lacks the discipline/skill/wherewithal to create good boundaries within a single code base when stakes are at their lowest, they absolutely don't have the skill or discipline to do ahead of time, across N code bases, and with a network in between all of them. Breaking your system apart too early, and when you know the least about it, and with the rationale that doing so will magically stop the problems that a lack of engineering skill creates, has, at least in the small slice of the world I've encountered, resulted in nightmarish levels of complexity (some of which I'm directly responsible for the reasons stated! (whoops!)).

BulgarianIdiot 4y ago
You can disagree with it and blame the developers, but the fact is that DDD fails basically every time, unless physical boundaries stop you from failing. It's like saying a good driver won't have an accident on a sharp corner of an icy road, but yet you have a ton of accidents on that corner on an icy road. Facts are facts. Just as it's a fact you can't hope every organization to be staffed by 100% geniuses who never make a mistake. Part of the problem is the platform itself. Most mainstream languages today ALL support shared mutable state. Meaning you can hold a pointer or a handle to something, mutate it, and someone else having the same pointer or handle has it changed under their nose. When you fetch, say, JSON over the network, the party who sent it to you can't change it under your nose either intentionally or accidentally. It's a snapshot of data you own, and you can make decisions on at your own leisure. Sure, the snapshot may get out of date by the time you send your next API request, but this contract is clear and obvious. While the entangled meshes of mutable code in say C, C++, Java, Swift, Python, JS, etc. etc. often make the mess unavoidable. Rust goes to some length to stop this problem, but it's a language that's low-level (by modern standards) and technical, and I don't think anyone uses it for enterprise automation exactly. Another problem are nominal (vs. structural) type systems. Well I don't have to explain, but when you fetch JSON from an API a nominal type won't stop you from reading that data, you care about the structure.
- hcarvalhoalves 4y ago
  Microservices alone don’t solve the shared mutable state problem, and make it even worse w/ network and eventual consistency.
  - BulgarianIdiot 4y ago
    They solve the mutable shared state problem that I'm specifically talking about. Which is that it's clear which state you own, and which state you don't own. "Shared" implies shared ownership, this is where the confusion comes from. When you ask an API about a user's profile, it's that API's user profile. But the API response itself is entirely yours. It won't change right under your fingertips. The original profile may change, but you know that the profile is not yours already.
    - treis 4y ago
      You don't need an HTTP boundary to make your own copy of data.
      - deleted 4y ago
        [deleted]
      - BulgarianIdiot 4y ago
        Do you religiously deep-clone every container you pass to a function? No. So it's one thing to say you can copy your data, another to know your data is guaranteed to be copied. Swift has value types which use pass-by-value semantics. Containers use copy-on-write. This is a language where you can quickly build value trees that you know are a guaranteed copy, isolated from whoever sent you this tree. But most languages have no such infrastructure. Java is adding record types, but they're immutable instead of in-place mutable, which is incredibly inconvenient to work with in nested data structures.
- za3faran 4y ago
  > Rust goes to some length to stop this problem, but it's a language that's low-level (by modern standards) and technical, and I don't think anyone uses it for enterprise automation exactly. Java's new type offerings are immutable (records, with value and primitive types in the works). Hopefully a push in the right direction.
theptip 4y ago
Why do you need to do it ahead of time? Typically what actually happens is you build a monolith, then note that one team needs to own one chunk, so you split it out into its own service. For example from my experience, splitting an Auth/User service for security/compliance, or splitting a Payment service for the same reasons. Or splitting out a core low-level platform layer that per-product teams can build atop, allowing each to iterate faster, while the Platform layer focuses on clean abstractions. Nothing in DDD or microservices says you need to sit down and design the service boundaries up-front, indeed most of the advice I’ve seen in the community suggests the opposite.

BulgarianIdiot 4y ago

You can disagree with it and blame the developers, but the fact is that DDD fails basically every time, unless physical boundaries stop you from failing. It's like saying a good driver won't have an accident on a sharp corner of an icy road, but yet you have a ton of accidents on that corner on an icy road. Facts are facts. Just as it's a fact you can't hope every organization to be staffed by 100% geniuses who never make a mistake. Part of the problem is the platform itself. Most mainstream languages today ALL support shared mutable state. Meaning you can hold a pointer or a handle to something, mutate it, and someone else having the same pointer or handle has it changed under their nose. When you fetch, say, JSON over the network, the party who sent it to you can't change it under your nose either intentionally or accidentally. It's a snapshot of data you own, and you can make decisions on at your own leisure. Sure, the snapshot may get out of date by the time you send your next API request, but this contract is clear and obvious. While the entangled meshes of mutable code in say C, C++, Java, Swift, Python, JS, etc. etc. often make the mess unavoidable. Rust goes to some length to stop this problem, but it's a language that's low-level (by modern standards) and technical, and I don't think anyone uses it for enterprise automation exactly. Another problem are nominal (vs. structural) type systems. Well I don't have to explain, but when you fetch JSON from an API a nominal type won't stop you from reading that data, you care about the structure.

hcarvalhoalves 4y ago
Microservices alone don’t solve the shared mutable state problem, and make it even worse w/ network and eventual consistency.
- BulgarianIdiot 4y ago
  They solve the mutable shared state problem that I'm specifically talking about. Which is that it's clear which state you own, and which state you don't own. "Shared" implies shared ownership, this is where the confusion comes from. When you ask an API about a user's profile, it's that API's user profile. But the API response itself is entirely yours. It won't change right under your fingertips. The original profile may change, but you know that the profile is not yours already.
  - treis 4y ago
    You don't need an HTTP boundary to make your own copy of data.
    - deleted 4y ago
      [deleted]
    - BulgarianIdiot 4y ago
      Do you religiously deep-clone every container you pass to a function? No. So it's one thing to say you can copy your data, another to know your data is guaranteed to be copied. Swift has value types which use pass-by-value semantics. Containers use copy-on-write. This is a language where you can quickly build value trees that you know are a guaranteed copy, isolated from whoever sent you this tree. But most languages have no such infrastructure. Java is adding record types, but they're immutable instead of in-place mutable, which is incredibly inconvenient to work with in nested data structures.
za3faran 4y ago
> Rust goes to some length to stop this problem, but it's a language that's low-level (by modern standards) and technical, and I don't think anyone uses it for enterprise automation exactly. Java's new type offerings are immutable (records, with value and primitive types in the works). Hopefully a push in the right direction.

theptip 4y ago

Why do you need to do it ahead of time? Typically what actually happens is you build a monolith, then note that one team needs to own one chunk, so you split it out into its own service. For example from my experience, splitting an Auth/User service for security/compliance, or splitting a Payment service for the same reasons. Or splitting out a core low-level platform layer that per-product teams can build atop, allowing each to iterate faster, while the Platform layer focuses on clean abstractions. Nothing in DDD or microservices says you need to sit down and design the service boundaries up-front, indeed most of the advice I’ve seen in the community suggests the opposite.