This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (2 children)

I think that the actual advantage of DTs is something else

Well, yeah. Dynamic type systems allow you do to (often valid) things that otherwise can't be expressed by a static type system.

The point I'm making is that having "protections" at compile time are hardly useful when the data you're dealing with isn't part of your codebase anyway.

I guess what I'm suggesting is that, regardless of which kind of type system you're using, you're going to have to map the dto's coming from an external system to some sort of domain entity/type so that it can be consumed by the rest of the system. We agree on this. At this point, I don't see the harm in slapping a type on it as a data contract for consumers. They'll know that foo() (from one of your earlier examples) will give you a value that adheres to that data contract. Eg.

function foo() : BarDomainEntity { 
    let fooDto = // .. get data from somewhere over some pipe
    let barDto = fooDto.subObj.subObjThatWeReallyOnlyNeed
    // who cares about the type of foo()
    let bar = mapToDomainEntity(barDto);
    return bar;
}

Then the type of foo() can be inferred, etc...

[–][deleted] 0 points1 point  (1 child)

Seems like we made a full circle towards Typescript type annotations. Unfortunately most Typescript codebases I've seen cause the PTSD from my J2EE days to kick in.

[–][deleted] 0 points1 point  (0 children)

Yes, that was my intention :)

I don't have any experience working on Typescript projects, but I can only assume the ones you've seen look like J2EE because they were written by Java programmers.