Question about dependencies between domains and external libraries.

[vduggen]

First of all, I wanted to thank you for the high-quality content; I have been learning a lot from you.

It's just a question of how I could improve, if necessary, on domain layer dependencies. In the case of creating an order, I have the part where I want to use some external library for the creation date or something similar, in this case, could I pass it as a parameter and have the use case provide me with this information? How could I do it?

And the other question is regarding dependencies between domains. In this case, could I also receive them as parameters, and the use case would give me this information?

Observation: I am Brazilian, and I used Google Translate for translation. I apologize if it is not clear.

[bespoyasov]

Hi!

First of all, I wanted to thank you for the high-quality content; I have been learning a lot from you.

Thank you! Glad to hear that 🙌

It's just a question of how I could improve, if necessary, on domain layer dependencies. In the case of creating an order, I have the part where I want to use some external library for the creation date or something similar, in this case, could I pass it as a parameter and have the use case provide me with this information? How could I do it?

I'm not sure if this is still relevant because the issue is closed but I'll answer just in case 😃

First of all, since I don't really know the project, its scope, the team, and the domain, my recommendation will be general. It won't be a perfectly fitting solution but rather just thoughts and ideas.

As for the question, I believe there were similar (not identical but similar) questions previously, so you might get some insight from my answers in in these issues:

• Is the domain level independent of the UI layer? #9
• Does the application layer depend on the adapter layer? #10
• How to define Domain in practice? #11

If we talk about this particular case, the answer would depend on the project size and the reasons why it's needed to implement this architecture style.

If the project is small, the domain itself is compact, the dependency list is short, and the rate of changes isn't that high, I don't see anything too scary in having the dependency in the domain layer.

It wouldn't be that “clean” but if a “cleaner” solution makes the code more complicated than necessary, then I'd probably sacrifice “purity” for conveniency and understandability.

(This also can apply for the functionality that doesn't depend on the third-party tool but only on the self-written helpers lib that just uses the language built-ins.)

If, however, the scope is large, or the code change rate is high, or the team is big and we need some constraints on how we write the code and organize the modules, then it might worth to split “service” functionality (third-party tools with adapters) and the application layer (domain & use case orchestration).

Then, the code might look somewhat like:

// Domain function:

function createOrder(user: User, cart: Cart, createdAt: Timestamp): Order {
  return {
    products: cart.products, 
    user: user.id, 
    createdAt,
    // ...
  }
}

// Application Layer:

type Dependencies = {
  timeSource: DateTimeSource;
  notifier: NotificationService;
  payment: PaymentService;
}

async function orderProducts(
  user: User, 
  cart: Cart, 
  { timeSource, notifier, payment }: Dependencies
) {
  // Call third-parties, prepare the data, perform all impure operations:
  const currentTime = timeSource.moment()

  // Run domain logic, if any:
  const order = createOrder(user, cart, currentTime);

  // Run the rest of the impure operations:
  payment.sendPayment()
  notifier.notify()
}

But again, the solution should come from the project's needs and if it's more complicated than necessary, or makes the code contrived, or creates unneeded abstractions, then it's probably not a good idea to use the approach 🙌

[vduggen]

Hello good morning, I had closed it because I was reading your article and I had not finished reading it, just below I found a section where you answered these doubts that I had, thanks for the answer here, another doubt that I have, I have been studying about this subject of how I could organize my frontend and I ended up reflecting on which cases I should have a better structured frontend and when I should leave it simple, I've been working on some projects, where I have more screens than by rules, one rule or another, something like that, if X information blocks some thing, cases where you prefer to keep it simple or go for something more structured, I found some people saying "if your frontend has a lot of rules, you should start thinking about something more structured", but I wanted to know more points to consider, I have some difficulties in knowing if I should do something more advanced or not, if you prefer I can create another issue or if there is another place to talk about it.

[bespoyasov]

I have some difficulties in knowing if I should do something more advanced or not

I probably won't be able to help without digging into the details of the project, its goals, and constraints.

Usually, I prefer to grow the complexity of the structure and the code slower than the complexity of the problems that this code should solve. If something can be solved using simpler solutions, I'd lean towards that direction.

(There are, of course, exceptions but again the decision will depend on the particular circumstances of the project 🤷)