A user requests latest news , the news get data from multiple sources (posts, users , photos, comments) . How would you model the news?
Is it good to have a gateway that couples these tables + a service that gets the data from the coupled gateway and handles the data as a response ? Or a domain model that couples the other models (this would mean to add in one of those gateways a joined long query that , in my opinion needs a separate gateway ).
I would create a NewsService, as it would be coordinating the creation of the news, but would defer any specific responsibility to the appropriate model. If it's a news feed, like in facebook, I would create another model, NewsItem which is created upon the entry of a new post, photo etc. This way, the responsibility of build the news would fall more into your domain model and your NewsService would be really just orchestrating the construction of the list. You could even, depending on your app, just use a NewsRepository.
Related
to give you a bit of context, I'm developing a game, an online soccer manager, and I have the following microservices:
Clubs
Season
The Clubs microservice takes care of the club management and the Season is responsible for the Season management.
One of the responsibilities of the Season service is return the league standings, with the club names and their positions. In the Season service, I only store the club_id, but to fulfill the request to return the standings, I would need also the club name, which resides in the Clubs service.
Now, I could implement a REST endpoint in the Clubs service to return the club name, but them those service won't be loosely coupled anymore.
As I saw from my readings, I have 2 options, and they are:
Have a clubs cache in the Season service, where it does the relationship between the club_id and club_name (Could be a database table). In this case the data will be duplicated (which is OK for most of the cases), but I need to keep in sync with the domain events dispatched by the Clubs Service.
The other option would be create another microservice to be used as API composition pattern. So this API would get data from both service, enrich the response and send back to the caller.
Now, I'm in doubt which approach should be taken. Which one has less downsides?
Both are described in Saga pattern. There are pros and cons of both. You have to choose based on your NFRs.
Let's say I have an application where I use multiple microservices. Two of them are USERS ( /users ) and CARS ( /cars ).
Given a page called rental history ( /users/{id}/history ) which lists the rented car of the users.
Should I introduce an intermediary microservice RENTAL ( /rental ) which would query the other two microservices for the best architectural design ?
What is the correct design if I wanted to deploy this app under different brands, which means USERS database would be different , but the CARS database would be shared between the application ?
I would strongly suggest that you have a rental microservice to coordinate the process of renting (and returning etc.) a car by a user. Then the logic only appears in the rental service, not spread out over however many other services (counting UIs and such as services for this purpose).
I would actually question whether different brands would need fully-different user services, because there'd be a lot of common functionality. It might make sense to have a general user service with brand namespaces user IDs (so that, for instance, the rental service doesn't need to know about brands) and some brand-specific facades (e.g. to add the namespace to the IDs and maybe even handle things like frequent renter programs).
I want to use the many to one and other DB Relationship in micro-service architecture. In monolithic architecture we can create the entity relationship easily as they belongs to same project but in micro-service architecture how we can achieve the same.
Example:
There is one userDeatil service and other is productDetail service.Now there is third service called orderDetail and an order will have userID and ProductIDs associated with it. So how can we manage the relationship between 'user and order' and 'order and product'.
I have searched over net but didn't able to get the fair idea.There is another thread having same query but not having the clear answer. Link
In my opinion your case is about how you specify your services especially how you define the bounded context of each service !!
According to the situation above-mentioned I don't see any reason why the product service should know anythings about orders (even if it s just the order-id) and backwards. One more problem I see in this case: your services will not work if one service is not available (E.g when the product service it not online, your order service will not be able to work, because he needs the product details from the product service...).
I Think you should rethink the bounded contexts of your microservices. You should keep in mind:
ensure a loose coupling of the microservices
a microservice has always to work even other Microservices are not available (Resilience / Reliability).
The DDD (domain-driven-design) paradigm with its tools provides her a great help to assist you, during the definition process of your services, you encourage these qualities.
So, the following is JUST an idea (it s not a recommendation and you should review whether it matters for your business case) :
It seems like the "order" process is your core business domain. So you have to focus on it.
The user service (i hope you mean here the customer and not a user in terms of authentication/authorization) has only the responsibility to manage the customers, and may be their adresses, bank-Accountings etc.. It should not know anything about your orders or products.
The same is valid for the product service. It owns only data about products. It has no relation either to the customer nor to the order-service.
The order service by itself deals only with orders and should own only data that belong to an order (like ship Adress and some information about the product-items ordered). I think the customer-Id is also important here to keep the relation between the order and the customer. This way you can e.g get all orders made by a certain customer-id....
I am reasonably new to the MVC pattern.
I have a model called Address which can be used in a few separate places throughout my application, such as:
Addresses against an order
Addresses against a customer
Addresses against a supplier
You can create these addresses on separate screens (such as order, customer or supplier maintenance), however they ultimately end up in the same address table, although each one adds the id into it's own respective table.
I don't want to have to have 3 copies of the code that creates the address model and saves it. Where does this logic fit? It currently sits in the order controller (as I have not yet written the customer and supplier part). Does it go in its own controller (Address) and simply get's accessed from the order,customer, or supplier controllers? Is it normal to call a controller from another controller?
I'm thinking that alot of my logic at belongs in my models but I'm not too sure.
At the moment, my controllers are quite heavy whereas my models really only have the getters and setters.
I am just getting started with MVC, and it seems like it will be a great way to go, once I manage to switch my thinking to it.
Most of the material I have come across seems to have a 1-1 relationship between models, views, and tables - ie each model represents a table and allows CRUD, plus more complex functions.
What if I have an Account Model, which would allow account creation and updating.
I would want to use a /signup view and controller to create() the account, but would want to use a /members/account view and controller to update, change pw, etc.
Would it be better to have a Signup Model, or am I ok with just using whatever model I need from multiple locations?
Also, say an account can have many users, but I want to create the first user at signup. I would like to run the account setup and user creation as a transaction. Should I have an Account Model and User Model, and work with both, or just have the signup create() function for Account create the default user?
I am using PHP with CodeIgniter
In general, what you want to do is most likely to consider your tables to be an additional "layer" below your model; the MVC concept generally doesn't deal too much with the implementation of backing issues; i.e. whether or not you're using DB tables or flat file storage or in-memory data representations.
What I would suggest is to look at the problem as one of having one layer that does interaction between your tables and your application; your "data objects" layer. Think of this as pure serialization. If you're using an object model, this will be your ORM layer.
Then you want to have another layer that defines the "business logic"; i.e. the interaction of your data with your data. This has to do with things such as how the Account interacts with the User, etc. The encapsulation here basically takes care of your high-level interactions. In this way, you can define the abstractions that make the most sense for your business requirements without needing to depend on implementation; for example, you can define a "UserAccount" Model, that will do all the things that you need to do to handle User Accounts; define all the things that you want that abstraction to do. Then, once you've got that abstraction down, that is your Model; you can then define, in the internal workings of that model, how the interactions occur with your persistence code.
In this way, you abstract out the persistence and implementation of your Model from the actual Model interface. So you can define your model as doing the things you want it to do without concern for the underlying implementation. The benefits of this are significant; the process of thinking about what you want your Model to do, in isolation from the way in which it will be doing it, can be very instructional; as well, if your backing data layer changes, your Model doesn't need to change; so you can prototype with a flat file, for example.