Hot answers tagged

78

Assumed you have some services which can use the same kind of DB system and version, if you use different database or db instances is a decision you should not need to make at design time. Instead, you should be able to make the decision at deployment time, something you can simply configure. Design your services to be agnostic of the place where other ...


28

It really depends on your scalability requirements, and how/if your microservice instances need to cooperate to provide a single result. It helps to know what the trade-offs are: Keeping it all in one database Easier configuration No coordination or communication with other instances of your service needed Easier to discover your full dataset System ...


25

Model: Fields that belong to the object, methods that help to get/set data from the object (a fullname accessor that returns first + last name) Service: Methods to perform operations with one or more models, see 'unit of work', transactions, etc... Employee::create should just take a set of data, perform model validation if necessary, and return an ...


13

It doesn't matter. The only scenario where it could theoretically matter is if one service needs to migrate to a different versions of the database. But even then, there's no real difference between having separate instances from the start versus migrating that one service from a shared instance to a separate one. I'd actually say that having separate ...


9

Considering domain layer is persistence ignorant and has no idea how to retrieve the data but only how to do operations on them, it cannot really touch the repositories itself. I would disagree with this part. Especially the last sentence. While it is true that domain should be persistence ignorant, it does know that there is "Collection of domain entities"...


9

In my humble opinion, the controller should be the "facade" itself, that means that the controller should decide which service to call, and the services should be in charge of generating the response object. What I would do is to define a method per action, and discriminate the service using REST naming, something like this: @Path("/") public class ...


9

Why is it in Application Layer then? As far as I can tell, because this is an application service -- more specifically, because the consumer of this service is the application, not the domain. For example, take a close look at BookingService.assignCargoToRoute, if we strip away the logging and exception handling, we see public void assignCargoToRoute(...


8

If your repository layer is properly abstracted (eg, the service layer and controller can only access the repository via interfaces), then: Having the controller access the repository directly simplifies that part of the code as it removes an unnecessary level of abstraction, but You are then coupling the controllers to both the service and repository ...


7

It is indeed possible to do what you describe- I am currently working on an application that uses the Asp.Net Auto-start feature to have a worker thread behaving like a windows service but hosted inside IIS so you keep all your code in one place. It is very handy and after the somewhat fiddly configuration it seems to work more or less as advertised ...


7

You could rename the directory to a new name and create a new empty directory by that name, both steps under the same lock (e.g., by locking the parent directory, but that depends on your specific file system). Then release the lock and empty the renamed directory. IMHO using this method you should be able to skip the renaming of each individual file.


6

First, as the comments point out, you aren't really talking about realtime here -- that has a pretty strict definition and implies lots of stuff that isn't really on the table. You are talking about connecting two systems in a near realtime sort of manner. Anyhow, yes, the best bet would be some sort of message queueing solution here. The POS system would ...


6

You don't have to argue about it for "days." In that amount of time, you can actually implement a microservice of the size you're describing both ways and compare for yourself. Look at how easy the code is to read. Look at how easy it is to write unit tests and integration tests. Honestly evaluate the code's coupling and cohesion. I can save you some ...


6

In "enterprise" systems, service discovery is often handled by the service advertising itself in a well-known location, known as a service registry. After the service has found an open port and completed startup, it contacts the service registry and provides its connection info. Other software that depend on the service check the service registry on ...


5

According to my experience, the Model layer within the MVC design pattern refers to every software component involved with data manipulation (POJOs, DAO, all the way to SQL, JDBC, and so on). Whereas the service layer is actually an addition to MVC: We know that the Model layer components are invoked inside the Controller layer. Once the latter is built, ...


5

I prefer to convert the JSON to business objects as soon as possible, and generally this is done in the REST controller class. There are reasons for this: JSON is a data transport format. In a large system there may well be other data transport formats (eg XML or CSV). So if possible your internal representation should be data format independent. Business ...


5

It is all a bit of semantics. A service would be a helper class, or in a sense a helper class would be a service. In terms of Laravel. Creating a service (which is a specific thing) would help code reuse and make testing easier. It is well worth getting over the hump of learning how to do. The number of services you need tends to grow as do the ...


5

It's a good question. Sometimes the complexities of the real world make it harder to see the big picture, and/or are in conflict with our mental models. I'll have to digress a bit before I get to your actual question, but bear with me. The key idea is that the very core of your application is the (software) model of the business problem you are trying to ...


4

You need to read Greg Young on set validation. Short answer: before you go too far down the rats nest, you need to make sure that you understand the value of the requirement from the business perspective. How expensive is it, really, to detect and mitigate the duplication, rather than preventing it? The problem with “uniqueness” requirements is that, ...


4

Having services in containers does not mean that they all have to be on the same server. Instead it makes it very easy to have them all on the same server some on different or all on different. You can start with containers sharing a server but then scale out with fast start up (development / light loads). The guidance for using containers is to help ...


4

There are no hard and fast rules. But usual place to implement is in the business logic layer. Also I think that field size validations are business logic. If you use a rich domain model you should implement validation in the entities. But if you don't have a rich domain model and the only interface you provide to the outside world is via your web API I don'...


4

Lets start with a quote form Evans in his DDD reference book: Sometimes services masquerade as model objects, appearing as objects with no meaning beyond doing some operation. Keeping this in mind, we can now look at the DDD definitions: AGGREGATE: A cluster of associated objects that are treated as a unit for the purpose of data changes. ...


4

There are three aspects of failure handling applying to your case: Informing the service user (important). Giving a failure response is the correct way to go. Normally, your user isn't interested in the details why the call failed, just the fact that it failed. That aspect is important and you already do it. Leaving the service in a consistent state (...


3

Design questions like these often tend to have no true or false answer. It depends heavily on the surrounding components and the bigger targets. Despite of this, here some things seem rather clear to me. So to your first question: This: Room room = something.findByLogin(name); is a task that clearly belongs to the model layer. You can imagine testing ...


3

Usually that type of guideline (that the majority of the logic should go in services) means that your business logic should be accessible through services rather than e.g. in an MVC controller. A service should be the interface to some business logic, but all the code implementing that business logic doesn't necessarily have to live in a service class.


3

The answer is Service + Thread. Don't put the socket in an Activity. The activity is for UI. It gets recreated when the user rotates the phone. You can run into problems when the user receives a phone call. Put your sockets in a Service. Your activity/activities can bind to the Service and use it's methods. Or you can use a Messenger to communicate between ...


3

There is no reason that multiple micro services can't share a common core library that contains (drum roll, please) all the common data access classes! Then your micro service is free to pick and choose which DAO/repository classes it needs. Maybe you need multiple repositories or data access objects in one micro service. The reason to separate them boils ...


3

I think it is more common to make smaller services. That gives you more options: You can deploy different services on different machines if needed. You can give each service account only the permissions that it needs, e.g. if some of the services need network access and some don't. If any of the services has a resource leak, you can restart it without ...


3

If Service Layer is doing nothing, just calling methods in DAO. Can my Service Interface just extend DAO Interfaces? No. You don't have a service layer for the sake of having a service layer. It's a layer that further hides your data source and how that's implemented and also adds coordination logic for the DAOs (Say you have an user action that involves ...


3

It's better to be consistent and always call the service layer even as a pass through. Consistency is more important than saving a few lines of uninteresting code. This allows you to add potential business logic to accommodate future changes, and can help act as a signal that you aren't separating your business logic as much as you should if you have a lot ...


Only top voted, non community-wiki answers of a minimum length are eligible