New answers tagged

4

The key thing to keep in mind is “microservices should be independently deployable and scalable”. If your framework and dependencies make your microservices need to be deployed en masse, you lose almost all of the benefit (and incur a lot more cost). That will drive a lot of your decisions about where to split things. Literal size doesn’t matter as much as ...


2

I would recommend the asynchronous approach. The main thing this buys you is service autonomy, which brings many benefits. One of these benefits is better availability. If the Dealer service is down, you can still process leads. If you're already storing dealer ids in the LXMS, presumably you are already doing some sort of asynchronous communication to get ...


1

Layers As best I can deduce your question can be restated as: Why should I go through the Business Layer of a Service, when I can just insert the data directly into its database? Lets contrast these two approaches. The Two Approaches If I go through the public interface to update the data. Cons: Its slower, the database is updated, but there is all ...


2

Guess it's a bit late but here is what I would do : I would put a wrapper around your part and the blackbox. This wrapper will handle the creation of the jobs and the pulling. You have to make it qo only him can pull on that service. The wrapper will publish event on each finish jobs. To avoid DOS, you should have a limit of how many jobs you can ask to be ...


0

Short answer: hide the github-service behind a service interface so that using github-mircorservice or linking against a github-library is a implementation detail that can be decided later. Using and maintaining a library is less expensive than having a seperate microservice. You need more reasons than "reusability" to justify the extra costs. Long answer: ...


0

Both, Neither Both are reasonable at twenty thousand feet. First Question Can Github support multiple concurrent connections? If it can there isn't any technical reason why each of your micro-services has to deal with a middle man. If it can't then there needs to be some kind of mediation. Its still possible for each micro-service to connect directly, ...


4

Your analogy is intereseting and heading in the right direction. Microservices are like user space drivers Yes and no: Yes, like user-mode drivers, microservices provide an independent functionality in their own tiny and independent process. Minix drivers run as independent process to offer a functionality that would otherwise be (or at least run ...


0

Your comparison is apt, but that is because you looked into the topics deeply and verified that it is. The mere fact that both concepts are called "micro-X" could have been deeply misleading, and often it will be.


2

The aim is to allow recipients of the message to do thing without asking more questions. If you can do this then your system overall is decentralised and you can reap the benefits of multiple independent processors of messages. What you are trying to avoid is a system where the message contains only an Id which the processor has to immediately query a ...


2

The main consideration should be whether the message contents can and should be processed in one step/transaction. If the 150 objects are independent, put them into separate messages so you can easily handle failures per object and possibly scale up by running multiple workers. If these 150 objects are some kind of parameter list for some function, keep them ...


0

I would choose neither option. I am failing to see a compelling reason to pass any repository to a domain method. Not only does it invert a dependency, it likely adds I/O to your domain. This is not ideal. Who is calling Order.CalculateDiscount(IRepository repo)? And what do the first few lines of this method look like? Something like var customer = repo....


0

For example, when creating an order, the existence of the Customer must be first validated This is a consistency constraint for me. If Customers and orders were two different aggregates, then Customers could know anything about an order or vice-versa. But it's also true that there are many ways to model the same domain. We could consider orders as en entity ...


1

Making the queue handler look at the type of the e-mail would make the microservice very domain specific. There are a few cases where this makes sense, but in general, you may want your microservices to be much more generic. How to find if you need it to be specific or generic? List the usages of the service. YAGNI; don't think necessarily about the usage ...


1

As is already visible from the comments, there is neither an easy nor an ideal way. It all depends on your application and your requirements. Nevertheless, an approach that might be possible for your system is, that the news service passes validation requests on to the user service and asset service when a new news object is created. So, when you receive ...


1

The flow Authorization, as horizontal concern, could be managed from API gateway. For each request, API gateway invokes authz service to decode authorization info (eg. jwt) or receives an error. In case of succesful authorization, call the internal API. Since business microservices are at lower level of your architecture, they should never distinguish ...


0

I don't know how much adopted is, but it's pretty sure that every B2B SaaS platform should deal with that kind of abstraction. When you build software that will be used from a single enterprise, you' ll have room to analyze and understand its domain and its behaviours, but when you build software for infinite, unknown enterprises, you have to find the ...


0

Forget about the data. Systems need to be modeled according to behavior if you want any chance at something even remotely maintainable at scale. Your diagrams only show the data your system is using, and it is confusing you because it is leading you to consider lines (arrows) of communication between entities that are actually all the same thing. Your data ...


0

I wouldn't do either of those things. If you want to create a maintainable (i.e. future-proof) system you should not rely on details like data, and instead rely on abstract business concepts. This is sometimes called vertical-, or feature-based splitting. This is the exact opposite of what you seem to be doing, which is basically having a microservice per ...


0

I think you are making it unnecessary complex by linking Organisation and Company to login accounts. Both are legal entities that can not actually take an action themselves. They need a human to act on their behalf and you have such a human already identified in your system as SoftwareUser. You can even take it a step further and conceptually separate the ...


0

Oauth with JWT works for clients auth. But internally, what I needed was a way to give each service an identity. SPIFFE exists for this purpose, and is implemented by service meshes (e.g. istio on Kubernetes with mTLS)


1

I would paraphrase your concerns as follows: A (mostly) one-to-one correspondence between commands and events not only requires more (boilerplate) code but also seems redundant. Having the business logic in the command handler seems the wrong place. Here is my 10 cents worth. Point 1. Yes, there is duplication. One principle of software development is to ...


0

You can just need to add a listener and a feed to your pattern. How you do this maybe dependent on your implementation, most commonly I've seen this in the form of writing multiple projections/events from the repository (or event store depending on which diagram in your question you are looking at). More recently I've seen more event streaming (e.g. Kafka) ...


1

Disclaimer: I don't promise that I've read all of that big-wall-o-text.... Let's take StackExchange's "close question" feature as an example. If we reach a state of having 5 VotedToCloseQuestion, where does the event ClosedQuestion come from exactly? The event is computed by the domain model in response to the 5th CloseQuestion command. Imagine if you ...


1

Usually, the assumption for a microservice architecture is that we want to be able to scale horizontally. This only works well if there are no differences between instances of the microservice. In particular, sessions or workloads should not be pinned to a particular instance, and it should be irrelevant which instance handles a task. However, that is not ...


0

this contains entities such as customers, bookings, services, etc etc. All these entities are related to each other @ the database level. It is actually how a monolith system looks like. What I am wondering is, should each of these entities (bookings, customers, services, etc) be their own API and microservice? The only ones capable to answer to this ...


1

Senior team member and manager think we should change each DB call to a microservice, with the reasoning that no one should be able to access the entity in given DB without connecting to microservice written over that DB(making a common gateway for that entity on given database) and said we should follow Database per service pattern. I think your senior ...


0

A microservice per entity is generally bad design because it will lead to all services talking to all other services. By definition, microservices need to have their own database and be able to autonomously perform their business capability, but you can rarely do any business logic with a single entity. For example, to manage bookings you'll need some ...


Top 50 recent answers are included