2

The application I am working on is written in TypeScript and I need to manipulate DateTime. I always avoid doing date/time calculations manually, because they have a lot of edge-cases. The Date class in JavaScript is, let's say, a funny implementation in my opinion. I would much prefer to use the immutable dates in the js-joda library.

In my case, the date checks I need to do are very important to the domain and I would like them to be checked there.

However, I've read/heard that it's a good idea to only use what the language offers in domain layer, thus not having external dependencies. Are there cases it's acceptable to add a dependency to the domain? Would moving the logic in a service layer be a better solution for the problem at hand?

1
  • 1
    The JavaScript “standard library” is so minimal that you can barely do anything useful with it. Pulling in extra libraries in order to be productive is perfectly fine. But you should avoid dependencies on external systems (like a database) or other bounded contexts, and should avoid imposing the structure of some framework onto the business logic.
    – amon
    Mar 10 at 16:37

1 Answer 1

4

Yes and no.

Yes, by abstracting external dependencies, you ensure that you can easily switch between different libraries. If there is a simple and straightforward way to wrap your library; go for it.

If you can draw up a simple interface which encompasses all of your interactions with the date structure; stop reading here and go create it. The rest of the answer is mostly only relevant in cases where such an interface leads to a prohibitive complexity or amount of effort to create.

However, when such an interface is getting too complex to wrap, this can become an exercise in duplicating the library's interface. This is where you need to make a judgment call. Is the effort of abstraction worth the reduced effort if and when you switch libraries?

In cases which require a high upfront effort and with a low chance of ever needing to swap it out or maybe even a low increase to the effort needed if you do end up changing libraries; it becomes less interesting to go through the effort of abstracting from the get go.

However, I've read/heard that it's a good idea to only use what the language offers in domain layer.

Yes; but reasonable arguments can be made that some libraries extend the "stock" language up to a point where it's considered as (and intended to be used as) a near-native part of the language.

One such example are architectural frameworks such as .NET. Technically, it's something outside of the scope of C# by itself. But in reality, there's no point in separating the two. Such frameworks cannot be reasonably abstracted, they function as the backbone of your application.

Similarly, the same argument can be made for specific libraries that are ubiquitously used as "the default". Coming from the .NET world, Newtonsoft (JSON serializer), Mediatr (mediator pattern implementation), NodaTime (improved DateTime implementation) come to mind.

This is a judgment call, and it hinges on whether you consider that date library to be part of your application backbone, or as an external dependency that you want to be able to swap out at your leisure. In the latter case, abstraction is required. In the former, it is not.

This is a hotbed for discussion, which boils down to where everyone subjectively draws their own line on purism. Some will take the stance that all libraries should be abstracted - and there's no point in arguing this when you draw your purism line differently from them. Different strokes for different folks.

There is no one true answer here. You have to make a judgment call based on the practicality, effort, and expectation of future maintenance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.