Some questions about standard. about the-standard HOT 5 CLOSED

@padnom So, brokers in general live in the same realm as your services and exposure components (say controllers for your APIs for instance). this is what you call Core project.

Infrastructure to me is three things:

1. Where you provision your cloud components
2. Where you define your build steps
3. Where you define your release steps

that's infra. very different from integration components.

In your scenario, I would have an ISqlStorageBroker and IMongoStorageBroker for each implementation.
The reason for that, is that your interface/contract won't be able to withstand both. So go that route.

from the-standard.

@hassanhabib
Thx for you reply.
I'm little bit confuse because in Infrastructure layer.
This layer contains classes for accessing external resources such as file systems, web services, smtp, and so on. These classes should be based on interfaces defined within the application layer.
usualy I saw Repositories implementation.

from the-standard.

@padnom the concept of infrastructure to give you access to external resources might not support your ability to access resources within the system you're running on.
For instance, let's say we want DateTimeBroker where are you going to put that? Is it in the infrastructure? but it's not exactly external?

The other thing here is that the approach you mentioned seems to rely heavily on foundation services (core logic) owning the contract and brokers having to adhere to it. At first glance, this seems very convincing. But then you truly try to switch brokers and now you end up writing business logic (selection, iteration or sequencing) into your thin layer of integration.

If we are trying to achieve true abstraction here. then we need to first understand that doing it in one step isn't realistic without breaking some rules. in The Standard abstract happens on two different steps.
First step is to abstract away native/external functionality. and the second step is to abstract away contracts.

There's also another aspect here in terms of sharing libraries to provide access to resources. I'm not sure this is the best route to go about that. creating centralized components that are used across multiple microservices always causes a single-point-of-failure situation.

Let's jump on a call and discuss this on Discord.

from the-standard.

Thanks, I understand better.
I would have liked to do this on discord.
Unfortunately, my English is so bad :D.

from the-standard.

@padnom my English isn't any better either lol
Closing this issue.

from the-standard.