5 ms·

The Java example you've provided is known as Domain Modeling, it's well described (and honestly greatly expanded on) in Domain Driven Design by Eric Evans. It

The Java example you've provided is known as Domain Modeling, it's well described (and honestly greatly expanded on) in Domain Driven Design by Eric Evans. It's applied heavily in the enterprise world simply because it's so powerful. In general as the domain logic becomes more complex the benefits of doing this increase. Actually, not encountering this style in code-base which is solving a complex problem is a massive warning sign for me. It usually means that concepts are poorly defined and that the logic is scattered randomly all over the code-base. Apps Hungarian is just a logical style: name functions, variables, types so that they're meaningful within your domain. The result of which is code which is very easy to understand for someone who understands the domain. This doesn't mean long names - if you're doing anything math intensive then using the short names which conform to the norms of the field is perfect. For a business process it probably isn't :)

radicalbyte 7y ago
It's particularly powerful if you can great an algebra of your domain. You can define invariants which are then enforced by the type system. I use this a lot when writing C# code and the whole experience is getting better with every new release. Microsoft keep adding awesome stuff like ADTs which make working with these types a dream.
- james_s_tayler 7y ago
  Do you have any resources you can recommend which describe how to create an algebra of a domain?
  - jen20 7y ago
    I’d recommend Scott Wlaschin’s excellent book “Domain Modelling made Functional”. The examples are in F# but the concepts apply much more broadly.
    - goostavos 7y ago
      +1 for that book. It totally changed how I thought about types and their role in programming.
    - tigershark 7y ago
      The best thing is that he writes F# in a way that is perfectly understandable by the domain experts so he can use the code as the ubiquitous language. In this way an intermediate representation to communicate with the users is not needed and there is nothing that needs to be kept in sync with the code.
    - james_s_tayler 7y ago
      Thanks!
    - monoideism 7y ago
      Agreed. This is a great book. It's changed the way I use statically-typed functional languages. This article is very much in the same vein.
    - kuroguro 7y ago
      Or watch a talk https://www.youtube.com/watch?v=1pSH8kElmM4 https://www.youtube.com/watch?v=1pSH8kElmM4
      - q-base 7y ago
        Thanks a lot for that video. Watched the whole thing on the spot. He is actually quite a good presenter and really gets the points across.
    - smush 7y ago
      Came here to post this. I second this book heartily. If you design your types to be DD with raw, valid, invalid data then by the time you actually get to the database or API, you are sure that your code has passed through however many compile-time enforced validity checks (if you use F# or similar static strong type PL) before it got to this point. That way, you don't need nearly as much defensive coding re: null checks etc. because the data has gone from 'some client typed some value in an input box, hope its valid' to 'this is an Address line that has been confirmed to be valid structure to pass to downstream systems'. Pit of success is so much better than peak of success, and much easier to get in a static typed functional language vs. an OO language in my experience.
smt88 7y ago
> Actually, not encountering this style in code-base which is solving a complex problem is a massive warning sign for me. This is very narrow-minded. DDD as a broad concept is good and something I practice. DDD in enterprise is a disastrous nightmare. When people on your team are wasting time Googling lingo to try to figure out what kind of object they need, where to put a file, or where a method should go, it's a huge red flag. I was on a team that seemingly spent all its time trying to figure out what the hell DDD was prescribing, let alone trying to figure out how to do it.
- MrGilbert 7y ago
  > [...] trying to figure out what the hell DDD was prescribing, let alone trying to figure out how to prescribe it. Well... If the carpenter needs to Google how to use a hammer and nails while at the construction side, something went terribly wrong, didn't it?
  - btschaegg 7y ago
    I would actually agree with you there, but I suspect that wasn't your point. A hammer is such a simple and obvious concept that it should not need to be googled. If anybody needs to do that anyway, you should not put the blame on the carpenter, but on the guy who "designed" the hammer. On a related note, I still very much am convinced that Don Norman's Design of Everyday Things is a great read for anyone who designs APIs; types in this argument function both as affordances and force functions, which are the exact reason why a hammer is such an obvious tool.
  - smt88 7y ago
    You seem to be implying that a dev who doesn't understand enterprise DDD is unqualified. That's not like a carpenter who can't use a hammer. It's like a carpenter who asks for a sketch of a project and instead receives a phone-book sized list of vague instructions that no one can agree on.
    - MrGilbert 7y ago
      > You seem to be implying that a dev who doesn't understand enterprise DDD is unqualified. I imply that a dev who doesn't understand DDD in a enterprise environment, is unqualified for working with DDD in an enterprise environment. As much as a carpenter is unqualified to be a carpenter if he doesn't know how to handle a hammer and nails. And I appreciate all the downvotes coming in.
gambler 7y ago
>Actually, not encountering this style in code-base which is solving a complex problem is a massive warning sign for me. There is a fine line between capturing some common meaning in a reusable type (e.g. Optional<T>) and spending most of your time crafting a straight-jacket of type restrictions that are supposed to thwart some imaginary low-level bug in the future. Java is actually a great example of how this mentality backfires in real life. The language, from day 1, had a zillion ways to force someone else to do something they didn't want to. Abstract classes. Private methods. Final classes. Etc. It was supposed to ensure good design, but in practice just led to the endless reenactment of the banana-gorilla-jungle problem. (https://pastebin.com/uvr99kBE https://pastebin.com/uvr99kBE) At the same time, the language designers didn't add such basic features as lambdas and streams until 1.8. This lead to creation of ungodly amount of easily preventable bugs, since everyone was writing those awful imperative loops.
- LoSboccacc 7y ago
  it's extremely useful especially at interface level but also in day to day coding, pity the people whose method signature is (string, string, string) because no ide can save them from the churn.
- radicalbyte 7y ago
  Java has just had a terrible steward in Oracle. Plus the community seems to like boilerplate code (see: Angular for more of that if you're into javascript). I switched to C# as my main language specifically because they were gaining awesome features like generics, lambda, LINQ. Since then it just got better and better. In the C# world you seem to encounter systems where the logic is either in: * UI event handlers * Methods on helper classes which consume a model generated from a database. * Domain modeled with classes with the logic split between the classes themselves and services which consume classes. In the first two cases the code tends to have a massive sprawling dependency tree which makes it harder to maintain. In the latter case you've usually got a better chance of having properly isolated code. Even if the isolation isn't super you at least have the logic well organised.
- monoideism 7y ago
  Banana-gorilla-jungle problem results from OOP. This article (and presumably, the GP) is describing encoding domain-driven logic in a statically-typed functional language, and thus the OOP issues are not a problem. Functional languages don't carry around their environment with them, so you just get a banana. No gorilla or jungle.
cjfd 7y ago
This can go two ways. One can end up with lots of different types that do nothing but wrap a string. On the other hand I have also seen a float being used to represent a price. The correct way is somewhere in between those two extremes. If you have some logic specific to a value, by all means, make it a type but if there isn't it just ends up with lots of boilerplate.
rzzzt 7y ago
I've heard "micro-types" being mentioned in this context: https://markhneedham.com/blog/2009/03/10/oo-micro-types/ https://markhneedham.com/blog/2009/03/10/oo-micro-types/

radicalbyte 7y ago

It's particularly powerful if you can great an algebra of your domain. You can define invariants which are then enforced by the type system. I use this a lot when writing C# code and the whole experience is getting better with every new release. Microsoft keep adding awesome stuff like ADTs which make working with these types a dream.

james_s_tayler 7y ago
Do you have any resources you can recommend which describe how to create an algebra of a domain?
- jen20 7y ago
  I’d recommend Scott Wlaschin’s excellent book “Domain Modelling made Functional”. The examples are in F# but the concepts apply much more broadly.
  - goostavos 7y ago
    +1 for that book. It totally changed how I thought about types and their role in programming.
  - tigershark 7y ago
    The best thing is that he writes F# in a way that is perfectly understandable by the domain experts so he can use the code as the ubiquitous language. In this way an intermediate representation to communicate with the users is not needed and there is nothing that needs to be kept in sync with the code.
  - james_s_tayler 7y ago
    Thanks!
  - monoideism 7y ago
    Agreed. This is a great book. It's changed the way I use statically-typed functional languages. This article is very much in the same vein.
  - kuroguro 7y ago
    Or watch a talk https://www.youtube.com/watch?v=1pSH8kElmM4 https://www.youtube.com/watch?v=1pSH8kElmM4
    - q-base 7y ago
      Thanks a lot for that video. Watched the whole thing on the spot. He is actually quite a good presenter and really gets the points across.
  - smush 7y ago
    Came here to post this. I second this book heartily. If you design your types to be DD with raw, valid, invalid data then by the time you actually get to the database or API, you are sure that your code has passed through however many compile-time enforced validity checks (if you use F# or similar static strong type PL) before it got to this point. That way, you don't need nearly as much defensive coding re: null checks etc. because the data has gone from 'some client typed some value in an input box, hope its valid' to 'this is an Address line that has been confirmed to be valid structure to pass to downstream systems'. Pit of success is so much better than peak of success, and much easier to get in a static typed functional language vs. an OO language in my experience.

smt88 7y ago

> Actually, not encountering this style in code-base which is solving a complex problem is a massive warning sign for me. This is very narrow-minded. DDD as a broad concept is good and something I practice. DDD in enterprise is a disastrous nightmare. When people on your team are wasting time Googling lingo to try to figure out what kind of object they need, where to put a file, or where a method should go, it's a huge red flag. I was on a team that seemingly spent all its time trying to figure out what the hell DDD was prescribing, let alone trying to figure out how to do it.

MrGilbert 7y ago
> [...] trying to figure out what the hell DDD was prescribing, let alone trying to figure out how to prescribe it. Well... If the carpenter needs to Google how to use a hammer and nails while at the construction side, something went terribly wrong, didn't it?
- btschaegg 7y ago
  I would actually agree with you there, but I suspect that wasn't your point. A hammer is such a simple and obvious concept that it should not need to be googled. If anybody needs to do that anyway, you should not put the blame on the carpenter, but on the guy who "designed" the hammer. On a related note, I still very much am convinced that Don Norman's Design of Everyday Things is a great read for anyone who designs APIs; types in this argument function both as affordances and force functions, which are the exact reason why a hammer is such an obvious tool.
- smt88 7y ago
  You seem to be implying that a dev who doesn't understand enterprise DDD is unqualified. That's not like a carpenter who can't use a hammer. It's like a carpenter who asks for a sketch of a project and instead receives a phone-book sized list of vague instructions that no one can agree on.
  - MrGilbert 7y ago
    > You seem to be implying that a dev who doesn't understand enterprise DDD is unqualified. I imply that a dev who doesn't understand DDD in a enterprise environment, is unqualified for working with DDD in an enterprise environment. As much as a carpenter is unqualified to be a carpenter if he doesn't know how to handle a hammer and nails. And I appreciate all the downvotes coming in.

gambler 7y ago

>Actually, not encountering this style in code-base which is solving a complex problem is a massive warning sign for me. There is a fine line between capturing some common meaning in a reusable type (e.g. Optional<T>) and spending most of your time crafting a straight-jacket of type restrictions that are supposed to thwart some imaginary low-level bug in the future. Java is actually a great example of how this mentality backfires in real life. The language, from day 1, had a zillion ways to force someone else to do something they didn't want to. Abstract classes. Private methods. Final classes. Etc. It was supposed to ensure good design, but in practice just led to the endless reenactment of the banana-gorilla-jungle problem. (https://pastebin.com/uvr99kBE https://pastebin.com/uvr99kBE) At the same time, the language designers didn't add such basic features as lambdas and streams until 1.8. This lead to creation of ungodly amount of easily preventable bugs, since everyone was writing those awful imperative loops.

LoSboccacc 7y ago
it's extremely useful especially at interface level but also in day to day coding, pity the people whose method signature is (string, string, string) because no ide can save them from the churn.
radicalbyte 7y ago
Java has just had a terrible steward in Oracle. Plus the community seems to like boilerplate code (see: Angular for more of that if you're into javascript). I switched to C# as my main language specifically because they were gaining awesome features like generics, lambda, LINQ. Since then it just got better and better. In the C# world you seem to encounter systems where the logic is either in: * UI event handlers * Methods on helper classes which consume a model generated from a database. * Domain modeled with classes with the logic split between the classes themselves and services which consume classes. In the first two cases the code tends to have a massive sprawling dependency tree which makes it harder to maintain. In the latter case you've usually got a better chance of having properly isolated code. Even if the isolation isn't super you at least have the logic well organised.
monoideism 7y ago
Banana-gorilla-jungle problem results from OOP. This article (and presumably, the GP) is describing encoding domain-driven logic in a statically-typed functional language, and thus the OOP issues are not a problem. Functional languages don't carry around their environment with them, so you just get a banana. No gorilla or jungle.

cjfd 7y ago

This can go two ways. One can end up with lots of different types that do nothing but wrap a string. On the other hand I have also seen a float being used to represent a price. The correct way is somewhere in between those two extremes. If you have some logic specific to a value, by all means, make it a type but if there isn't it just ends up with lots of boilerplate.

rzzzt 7y ago

I've heard "micro-types" being mentioned in this context: https://markhneedham.com/blog/2009/03/10/oo-micro-types/ https://markhneedham.com/blog/2009/03/10/oo-micro-types/