5

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
    Commented Mar 10, 2022 at 16:37

1 Answer 1

9

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.

3
  • I generally agree with your suggestions. I do not agree with your last paragraph though. I think there is a heuristics to determine if a library may or may not be introduced to your domain. If the concept is a commodity concept (as in terms of wardley evolution stages) it is thus accepted and solved. You may rely on that. Don't try to reinvent that wheel (e.g. currencies). If your concept is in genesis or custom build you should avoid alienating a stock solution towards your needs. Commented Feb 6 at 14:16
  • @bastianowicz: It seems to me that you're arguing the specifics of making said call rather than disagreeing that a call needs to be made here by weighing up the relevant concerns.
    – Flater
    Commented Feb 6 at 21:41
  • Sorry I did not want to discredit your suggestion at all. I just wanted to add that there are a lot of methods and models approaching that one could use to decide. While I think gut feeling and subjective prespectives are great to start off we should then use these tools, models and methods to validate our subjective perspectives. This should be a collaborative process of many. Now that I read your answer again I think this is basically what you wanted to state out in first place. Commented Feb 8 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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