Hot answers tagged

68

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 ...


57

Martin Fowler's book "Patterns of Enterprise Architecture" states: The easier question to answer is probably when not to use it. You probably don't need a Service Layer if your application's business logic will only have one kind of client - say, a user interface - and it's use case responses don't involve multiple transactional resources. [...] But ...


33

Adding a service layer because you have evaluated the idea and concluded its the best approach: good Adding a service layer because that's what all the cool kids are doing: bad If your gut says you don't need one, then don't make one. One of the more disappointing developments in the programming world over the past 10 years or so is that it has become ...


22

There are many factors that go into the decision of creating a service layer. I have created service layers in the past for the following reasons. Code that needs to be re-used by multiple clients. Third party libraries that we have limited licenses for. Third parties that need an integration point into our system. Centralizing duplicated business logic. ...


18

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 ...


16

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 ...


12

First of all, transaction management should be done on service layer, not on DAO layer as that would create a lot of performance overhead (to deal with appropriate transaction isolation level and propagation at each different method). Also, the scope of a unit of work comes from the service layer instead of the data access layer: imagine performing a ...


12

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

Not allowing "direct database access" from an application allows the underlying database, and even the schema, to change without having to change the client applications. Clients simply code to the service interface, never needing to know how the data is persisted.


7

It's dangerous. If it's not publicly documented, then they won't have any compunction against breaking backward compatibility, or just breaking it entirely. It may be relying on undocumented web apis that might disappear tomorrow.


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.


7

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"...


7

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(...


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

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 ...


5

Adding an interface (a service layer is a type of interface) takes time. A good one takes a lot of time to design and test. It is very important to get it right on the first try because changing it later breaks all the clients. Also, consider that you probably won't know what needs to be in that interface until you have a second client with slightly ...


5

Most Service Layers I've seen are a complete mess. Services tend to have a lot of different methods, 1500 LOC are not rare. The different methods have nothing in common, but do share code. This results in high coupling, low cohesion. It also violates OCP, because every time a new operation is needed, you have to modify the code instead of extending the code ...


5

The best practice is a combination of the two: if it is a real error, (something that should not really happen,) then you should throw an exception. If it is not a real error, but something that may happen within the regular course of things, then the function should return some sort of a result enum. In your case, without knowing the specifics and just ...


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 ...


5

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 ...


4

I would recommend using Parallel.Net and PLINQ instead of explicit multi-threading. It's easier to manage, is more lightweight and will adapt itself to the numbers of core's you have Learning resources http://msdn.microsoft.com/en-us/concurrency/bb895950.aspx


4

I agree with Ray Toal's point. Another is that a service that owns its own data becomes the only place where business rules to guarantee its integrity and proper usage need to be maintained. Maintain it in one place rather than forcing clients to duplicate that logic. Keeps things nice and DRY.


4

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 ...


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

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 ...


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. ...


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