BeerId structure

[GenFlogi]

Hello fellow programmers. In the company I am working at, we are currently creating some coding guidelines and structures to streamline our PR process a bit better. We work with JHipster Lite and I stumbled upon this part of the dummy application:

public record BeerId(UUID id) {
  public BeerId {
    Assert.notNull("id", id);
  }

  public static BeerId newId() {
    return new BeerId(UUID.randomUUID());
  }

  public UUID get() {
    return id();
  }
}

Now my question is, what exactly is the reason for wrapping the id in its own record other than immutability? Is this a design pattern I am too stupid to find information about? What are the benefits of using this in comparison to just adding the UUID to the Beer class?

Thanks in advance for any help! :)

[DamnClin]

Hello,

This is done to avoid primitive manipulations and type everything.

In my domain, all IDs will typically be UUID so I want to type them since, as an example, a BeerId is not a ShopId.
Another reason is to attract features: If I have a type wrapping a primitive, if I need to do something on that primitive it will be natural to add the operation in the wrapper class. With a really low cost I'll end up with very specialized, easy to tests classes (and this is a good news)

You can look for Type Driven Development or read "Domain Modeling Made Functional - Scot Wlashin" for more on this approach

Hope that helps

[GenFlogi]

Yeah, that makes total sense.
Thanks for the explanation!