Hot answers tagged

404

In order to define what a service's responsibilities are, you first need to define what a service is. Service is not a canonical or generic software term. In fact, the suffix Service on a class name is a lot like the much-maligned Manager: It tells you almost nothing about what the object actually does. In reality, what a service ought to do is highly ...


122

Layers, modules, indeed architecture itself, are means of making computer programs easier to understand by humans. The numerically optimal method of solving a problem is almost always an unholy tangled mess of non-modular, self-referencing or even self-modifying code - whether it's heavily optimized assembler code in embedded systems with crippling memory ...


63

The fundamental motivation is this: You want to be able to rip an entire layer out and substitute a completely different (rewritten) one, and NOBODY SHOULD (BE ABLE TO) NOTICE THE DIFFERENCE. The most obvious example is ripping the bottom layer out and substituting a different one. This is what you do when you develop the upper layer(s) against a ...


63

In my opinion, that's absolutely not how it's meant. And it's a violation of DRY. The idea is that the entity / domain object in the middle is modeled to represent the domain as good and as convenient as possible. It is in the center of everything and everything can depend on it since the domain itself doesn't change most of the time. If your database on ...


42

As for your title, I don't think the question makes sense. The MVC Model consists of data and business logic. To say logic should be in the Service and not the Model is like saying, "The passenger should sit in the seat, not in the car". Then again, the term "Model" is an overloaded term. Perhaps you didn't mean MVC Model but you meant model in the ...


27

I'm working on the greenfield project right now and we had to make few architectural decisions just yesterday. Funnily enough I had to revisit few chapters of 'Patterns of Enterprise Application Architecture'. This is what we came up with: Data layer. Queries and updates database. The layer is exposed through injectable repositories. Domain layer. This is ...


27

Repositories and their placement in the code structure is a matter of intense debate in DDD circles. It is also a matter of preference, and often a decision taken based on the specific abilities of your framework and ORM. The issue is also muddied when you consider other design philosophies like Clean Architecture, which advocate using an abstract ...


22

The "layers" that we describe when we describe software systems are abstract concepts. To the computer, all it gets to see is a featureless stream of one opcode after another, no matter which layer, which class or which method it originally came from. In this sense, they are not "real" at all. However, layers (and classes and methods) are useful for ...


14

A UoW might involve one ore more aggregated roots and repositories. No, absolutely not. That misses the entire point. We always change one aggregate at a time (one per transaction). Transactions are typically coordination between the application component and the persistence component. The application starts a transaction (UoW, if you like), reads the ...


14

I am comfortable to say that an object belonging to a layer can depend on objects from lower layers To be honest, I don't think you should be comfortable with that. When dealing with anything but a trivial system, I'd aim to ensure all layers only ever depend on abstractions from other layers; both lower and higher. So for example, Obj 1 should not depend ...


13

Layers, Onions, Ports, Adapters: it's all the same Since this article makes clear that onion is equivalent to 3 layer + application of the Dependency Inversion Principle (DIP), then the question becomes "where should I prefer to use DIP?" I'd say any non-toy project. Using DIP allows the core of your code to be more isolated, testable and maintainable. When ...


12

There is a big difference between the application layer and the presentation layer from a DDD view point. Although DDD centers around how to model the domain using the DDD building blocks and concepts such as bounded contexts, Ubiquitous language and so, it is still vital to clearly identify and separate the various layers in your app. The architecture ...


10

This is one of those things that really depends on the use case. The overall point of a service layer is to consolidate business logic together. This means that several controllers can call the same UserService.MakeHimPay() without actually caring about how the payment is done. What goes on in the service may be as simple as modifying an object property or ...


10

The easiest way to illustrate why programmers shy away from putting domain logic in the domain objects is that they're usually faced with a situation of "where do I put the validation logic?" Take this domain object for instance: public class MyEntity { private int someProperty = 0; public int SomeProperty { get { return this....


10

Often an abstraction layer is commonly used to 'abstract' away detail. Say you had a program for moving money around between different banks. There is a function for moving money to BankA, and a different function for moving money to BankB and so on. The different functions might exist because the information that different banks request varies (As a ...


10

Yes, objects in one layer can have direct dependencies among each other, sometimes even cyclic ones - that is actually what makes the core difference to the allowed dependencies between objects in different layers, where either no direct dependencies are allowed, or just a strict dependency direction . However, that does not mean they should have such ...


9

I think the answer is clear if you read Martin Fowler's Anemic Domain Model article. Removing the business logic, which is the domain, from the domain model is essentially breaking object oriented design. Let's review the most basic object oriented concept: An object encapsulates data and operations. For instance, closing an account is an operation that an ...


9

It sounds like you're describing the onion architecture, a form of n-tier architecture -- which is just a fancy way of saying it has components broken out into layers. The layer you're focusing on is the Infrastructure layer. Data is the most common component of infrastructure. But other functions can be contained in separate libraries in the same layer. ...


8

There are two facets to this problem and both should be satisfied for a good application to work: Fail Fast - having the user fill all the data, press the action button, wait 5 seconds, only to fail since some text at the beginning of the form should be at least 3 characters, or a dash has been forgotten is a very bad experience - do your security and ...


8

You actually got it right. And there is no violation of DRY because you accept SRP. For example: You have a business-Method createX(String name) then you may have a Method createX(String name) in the DAO-Layer, called within the business-Method. They may have the same signature and maybe there is only a delegation but they have different purposes. You can ...


8

In the MVC design pattern, the Controller part is responsible for translating user actions into modifications of the various Model classes that are involved in a piece of functionality. There is no one-to-one relation between Controllers, Views and Models. In particular, if a user action requires changes to multiple Model classes, then it is the ...


8

It is unfortunately a popular form of DDD. I say unfortunately because it completely ignores the core principles of DDD, that is the actual modeling of the problem. Having pure data structures does nothing to tell the reader what is happening, what problems are being solved, it does not use the Ubiquitous Language, since getting/setting stuff is rarely if ...


7

So besides adding the code for getting screws, I had to modify 4 lines. This would increase linearly with the amount of layers. I think this is a fallacy. When you add another kind of table part, you will still have only to change 4 lines of code in your "object construction layer". The layers above the "object construction" layer in your code will just ...


7

What you're trying to do is implement the facade pattern. Basically you want to put a simpler face on the core code. You'll probably want to create a set of classes that provide a 1:1 mapping for each core class, then use the facade classes in place of the core classes. If the core services are just a bunch of methods in some big monolithic class, then you ...


6

Whether a component does work synchronously or asynchronously is an implementation detail. Your design choice for each layer should be independent. You stated a use case for the UI layer being asynchronous, it needs to not lock up so it should be asynchronous. For each other layer if they have a use case for being asynchronous then make them asynchronous ...


6

The problem you are facing is an instance of a general problem that we quite often face in Software Engineering: Molding the tools to bring them to our specific problem domain by means of abstraction/conversion layers. You have an application which solves a problem. The entities that it contains, manages, and interacts with are entities that belong to the ...


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

Usually the naming of the layers depend on the architectural approach: The traditional layering is presentation / business logic / data access layer. Another popular variant is Fowler’s presentation / domain logic / data source layer. More recent architectures were inspired by the (data neutral) hexagonal architecture and use a more concentric idioms, ...


5

Atwood's advice from 2004 rings true still today, only we now have the benefit of ORM as well. http://blog.codinghorror.com/who-needs-stored-procedures-anyways/ Stored Procedures should be considered database assembly language: for use in only the most performance critical situations. There are plenty of ways to design a solid, high performing data ...


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