Hot answers tagged

87

Sandi Metz, a renowned software engineer and author in the Ruby ecosystem, has a great blog post and a talk where she also talks about the relationship between duplication and abstraction. She comes to the following conclusion duplication is far cheaper than the wrong abstraction And I completely agree with her. Let me give you more context to this quote....


87

Whenever a developer asks "what's the point of doing this?", what they really mean is "I see no use case where doing this provides a benefit". To that end, let me show you a few examples. All examples will be based on this simple data model: A Person entity has five properties: Id, FirstName, LastName, Age, CityId And you can assume ...


70

Duplication can be the right thing to do, but not for this reason. Saying "we might want these three places in the code base to behave different even though right now, they're identical" is not a good reason for large-scale duplication. This notion could apply to every system, and it could be used to justify any duplication, which is obviously not ...


34

If people start reasoning about design with the words "if tomorrow", this is often a big warning sign for me, especially when the argument is used to justify a decision which includes extra work and effort, for which noone really knows if this will ever pay off, and which is harder to change or revert than the opposite decision. Duplication of code reduces ...


32

I would suggest doing neither. Trying to enforce a technical layering with a package structure leads to a lot of entanglement in your application. Not to mention the fact that we try so hard to hide everything behind a service interface and the first thing we do (mostly due to packaging) is make everything a public class. This becomes painful when there is ...


29

We don't need the frameworks. It is entirely possible to implement dependency injection manually, even for a relatively large project. On the other hand, using a framework makes it easier, particularly one based on annotations or automatic detection of dependencies, as it makes the process simpler: if I decide that I need a new dependency in a class, all I ...


23

I think an important factor is who your service clients are. If your service layer is just an architectural boundary between layers in your own project, and the service client is within the same trust realm, then it is ok to relax things, and let unchecked exceptions bubble out to the controller layer, or the service client. However, for public facing ...


19

Here is one of my favorite kick-off examples of structure for your spring rest app. 1. Separation of layers, each layer is an individual module/project REST API Packaged as war (Could be jar if you are using spring boot with embedded server. Spring boot doc clearly explains how to deploy the so-call uber jar. It is deadly simple.) It has rest ...


18

Your new architecture is also not derive from Domain Driven Design. Of course in context of tactical patterns (as strategy patterns scope go beyond the code). In Domain Driven Design you have plenty useful building blocks which can help you with managing accidental complexity of your system. But before you start tot apply them you need to answer very ...


17

Why do we need DI (Dependency Injection) at all? The DI mechanism separates object production from object consumption. The dependecies an object needs are delivered transparently from the outside. The advantage of the mechanism is clear: You could anytime swap out dependencies, e.g. usìng a Null Object for testing purposes. How is it done? There are ...


16

If you did go for microservices to benefit from scalability, loose coupling, and easy independent modification of each service, the you should stick to it to the maximum possible extent. Overall architecture I think that the best approach would be: have a microservice for general user information management; keep microservice specific user ...


15

No, you should not wrap DAO exceptions in a web application It's a lot of noise in the code for zero benefit. DAO exceptions are unchecked exceptions for a good reason. The application code cannot do anything useful to recover from a DAO exception. The real problem is here: ... it'll be caught by a JSP showing an error message to the end user. Fix this ...


14

At jClarity we've definitely followed this approach. We have a 'pure' HTML5 front end - AngularJS, HTML, CSS and a host of Javascript micro frameworks which is a separate project to the backend - vert.x with a variety of verticles coded in separate JVM languages as appropriate. The trick is to have a well defined messaging API between the two that is tested ...


14

What does the Spring framework do? Spring is as today not only, what was known as a simple framework, it is a complete ecosystem. Topics covered by the spring ecosystem: Spring Framework (e.g. Dependency Injection, AOP ...) Spring Cloud Spring Data Spring Security Spring Batch Spring Social See here for full coverage of the ecosystem. It is possible to ...


14

Both controller layer and service layer expose certain interfaces. Interfaces define contracts on how the interface should be used. Contract usually means which arguments (and its types and values) are expected, which exceptions can be thrown, which side effects are created etc. Now, your validation is essentially enforcement of the contract of controller ...


14

Duplication to prevent coupling. Let's say that you have two big systems and you force them to use the same library. You may be coupling the release cycle of both systems. This may not be too bad but let's say that one system needs to introduce a change. The other needs to analyze the change and may be affected. Sometimes it may break things. Even if both ...


12

ADM is a good pattern for a solution of distributed services such a microservices. It fits many of today's web based business cases. Consider if we have an Order Domain object. With an OOP approach we would add Order.Purchase() Order.Cancel() etc. It would work well in a desktop app, where we hold orders in memory and do multiple things to the same instance....


11

In its broadest sense, a "transaction" is a group of actions that should be performed as if they were a single "bulk" action. The term is most often used in the context of databases, but it can be applied to many kinds of programs (particularly ones that implement a command pattern). When we're talking about databases, and often even if we aren't, we want ...


11

Repeat after me: REST and asynchronous events are not alternatives. They're completely orthogonal. You can have one, or the other, or both, or neither. They're entirely different tools for entirely different problem domains. In fact, general purpose request-response communication is absolutely capable of being asynchronous, event-driven, and fault ...


10

The main reason one would use exception wrapping is to prevent the code in the business layer from having to know about every possible exception in the system. There are two main reasons for this: Consistency: declared exceptions aggregate towards the top of the call stack. If you do not wrap exceptions, but instead pass them on by declaring your methods to ...


10

I don't think that article is implying that every method should should be logged that way, it's just saying when you're logging make sure you capture the context in which the log occurred. For example, if you have a log which says only "User cannot be found", if you're actually trying to understand the scenario which lead to that log then you probably need ...


10

Static is not a good idea, for many reasons: They are harder to mock in unit tests Permanent memory consumption¹ Is procedural And some other disadvantages Almost every disadvantage above can also be used to explain why static Spring beans is a bad idea. It increases the coupling between classes, as some classes need other classes, and so on. Having ...


9

An architecture is the the abstract design concept of an application. Basically, a structure of the moving parts and how they're connected. A framework is a pre-built general or special purpose architecture that's designed to be extended. If an architecture is the design of a structure, a framework is the architecture of a foundation. Frameworks are ...


9

Agree with @ericW's comment, and just want to add remember you can use initializers to keep your code compact: @Autowired private Converter converter; or private Converter converter = new Converter(); or, if the class really has no state at all private static final Converter CONVERTER = new Converter(); One of the key criteria for whether Spring should ...


9

It would be wasteful to always fetch the entire objects. First I would question this. If your objects are well-designed and not too bloated, the performance and memory overhead of fetching them completely instead of getting them partially is often negligible for most real-world cases. The performance of SQL queries over a network are way more dependend on ...


8

You pretty much hit the nail on the head. Dependency injection is a great choice when you want to get dependencies that are known and unchanging at runtime or compile-time, depending on how you configure. Let's assume that you have a mailer in your application implemented by IMailer and you can use a TextBasedMailer or HtmlBasedMailer. You either build the ...


8

Remember, the original GoF book has the full title "Design Patterns. Elements of Reusable Object-Oriented Software.". And most of the GoF patterns have that purpose - build software which can be put into libraries and/or frameworks and reused in a wide range of use cases, in a black-box manner, mostly following the open-closed principle. So if one is not ...


8

Most frameworks already use a lot of known software design patterns. So you are using design patterns unknowingly. That said, I would strongly suggest you to try learning at least the most common ones. It's funny. In the other hand, in a framework, your classes "fall into place" within the design of the framework, but you have to code your business logic ...


8

There is no "correct" answer here. It's really about finding the tradeoffs you're happy with. Sharing one model across layers trades coupling for development speed. It will allow you to get your code working faster, but it inherently couples all your layers together. A change to the model in the Service layer will affect the models the API consumer sees. ...


8

Before blaming Hibernate for performance issues, you should profile your application. By profiling a given request (if the whole application feels slow, just take any request), you'll get a more precise picture of what exactly is slow. Depending of what you discover, the solution for improving performance would be radically different. Some examples: The ...


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