75
Bob Martin is clearly exaggerating to make his point more clear. But what is his point?
Does he just want people to stop using SQL/Relational Databases because of SQLi attacks?
To my understanding, in that blog post (your first link) Martin tries to convince people to stop using SQL, but not relational databases. These are two different things.
SQL is ...
69
The Clean Architecture suggests to let a use case interactor call the actual implementation of the presenter (which is injected, following the DIP) to handle the response/display. However, I see people implementing this architecture, returning the output data from the interactor, and then let the controller (in the adapter layer) decide how to handle it.
...
58
Bob Martin's opinion is just that; one man's opinion.
A programmer is expected to understand the system he is writing well enough to exercise reasonable care about its security and performance. That means that, if you're talking to a SQL database, you do what the Bobby Tables website says to do: you sanitize your input data. It means that you put your SQL ...
51
How many ingredients are necessary for a meal? How many parts do you need to build a vehicle?
You know that you have too little abstraction when a little implementation change leads to a cascade of changes all over your code. Proper abstractions would help isolating the part of the code which needs to be changed.
You know that you have too much abstraction ...
43
My advice? Do not share these DTOs among the applications in any kind of library. Or at least don't do this right now.
I know, seems very counter-intuitive. You are duplicating code, right? But this is not a business rule, so you can be more flexible.
The service that sends the DTO needs to be rigid in his message contract, like an Rest API. The service ...
43
Having a "Map object that keeps track of all the cells to which it can travel" looks to me like an example of premature optimization.
Instead of remembering all those cells for each piece "just in case it could become slow", why not give a piece a method with the board as parameter, which returns the related List<Cell> (or Map<Direction, ...
35
Throwing an exception is simply an additional way of making a method return a value. The caller can check for a return value just as easily as catch an exception and check that. Therefore, deciding between throw and return requires other criteria.
Throwing exceptions should often be avoided if it endangers the efficiency of your program (constructing an ...
31
There is absolutely no reason for returning true on success if you don't return false on failure. What should the client code look like?
if (result = tryMyAPICall()) {
// business logic
}
else {
// this will *never* happen anyways
}
In this case, the caller needs a try-catch block anyways, but then he can better write:
try {
result = ...
24
Really? No Possible Valid Use Cases?
While I agree that hard-coding is generally an anti-pattern or at least a very bad code smell, there are plenty of cases where it makes sense:
simplicity (YAGNI),
the input is actually constant and will never change (ie it represents a natural or business constant or an approximation of one. e.g. 0, PI, ...),
embedded ...
24
The problem with design patterns can be summed up with the proverb "when you're holding a hammer, everything looks like a nail." The act of applying a design pattern is not improving your program whatsoever. In fact, I would argue that you're making a more complicated program if you're adding a design pattern. The question remains whether or not you're ...
22
Introduction
Entity–component systems are an object-oriented architectural technique.
There is no universal consensus of what the term means, same as object-oriented programming. However, it is clear that entity–component systems are specifically intended as an architectural alternative to inheritance. Inheritance hierarchies are natural for expressing ...
22
My suggestion is to make things as simple as possible. The more information you give to an object, the more complex it becomes, and the harder it is to keep track of it.
Let's break your program down into layers. What is there?
The pieces. They only know what kind of piece they are, and what color they are (black or white)
The board. It knows only about ...
20
Neal Ford's keynote on Evolutionary Architecture can be found here.
Paraphrasing:
Architecture is the decisions
that you wish you could get right early
in a project, things that people perceive
as hard to change. But what if we built
architectures that expect
change?
An evolutionary architecture supports
incremental, guided change as a ...
18
NO. And I'm surprised how many people voted otherwise!
Paradigm
It's Data-Oriented a.k.a. Data-Driven because we are talking about the architecture and not the language it's written in. Architectures are realizations of programming styles or paradigms, which can usually be unadvisably worked around in a given language.
Functional?
Your comparison to ...
17
I think you're expecting too much of the pattern you're using. CQRS is specifically designed to address the difference in model between query and commands to the database, and MediatR is just in-process messaging library. CQRS doesn't claim to eliminate the need for business logic like you're expecting them to. CQRS is a pattern for data access, but your ...
17
What is he actually saying?
Is he saying replace SQL with No-SQL technologies?
TL;DR: Yes (sort of)
In a more recent talk than the one you linked to on basically the same topic he says: "The database is a detail. Why do we have databases?".
He claims database came to be to make data access from spinning disks easier, but in the future "[...] ...
12
As I can see from the link, PubSub pattern is not an OOP pattern, but rather messaging pattern, which is a network architectural pattern.
Reactor pattern is something related to servers' request handling with single-threaded event loop. Again, the link shows some good examples like Node.js, Netty, Twisted, etc.
Finally, Observer is OOP design-pattern which ...
12
In a discussion related to your question, Uncle Bob explains the purpose of the presenter in his Clean Architecture:
Given this code sample:
namespace Some\Controller;
class UserController extends Controller {
public function registerAction() {
// Build the Request object
$request = new RegisterRequest();
$request->name = $...
12
When it comes to Microservices, services' development life cycles should be independent too.*
Different SLDC and different dev teams
in a real MS system, there could be several teams involved in the development of the ecosystem, each of which in charge of one or more services. In turn, these teams might be located in different offices, cities, countries, ...
12
What are some approaches used in financial applications to prevent deposit/withdrawal sync problems?
Transactions
A transaction wraps all of the required steps for a particular business operation and guarantees that either all of the steps succeed or they all rollback to the original state in the database before the transaction was started.
Further Reading
How are Cassandra transactions different from RDBMS transactions?
11
I wouldn't do option 2, because then you have forever convolved your object's construction with boost property tree parsing. If you're comfortable with a class that needs that many parameters, you should be comfortable with a constructor that needs that many parameters, such is life!
If your main concern is code readability, you can use the builder pattern, ...
11
We've had a few problems where a contractor changed something in a common project and unknowingly this breaks a number of other solutions
That's is unfortunate
We're currently trying to decide a new software architecture in our company
STOP.
You have a process problem, not an architecture problem.
A much simpler, and more valuable, fix to this would ...
11
It depends on the widget.
If the widget is rare and expensive (exactly 10 Ferraris), then the approach you're following is correct. Of course, you also need to account for inventory that's being returned but hasn't been restocked yet, inventory that's out for repair, etc.
If the widget is a bit more common (5,000 wrenches) then the usual approach is to:
...
11
Is this approach to making these key Objects easily available when needed good architecture? Is there a better approach to this issue?
The much maligned singleton pattern occasionally has it's uses but I'm not seeing it here. You say you have four or five key objects that are needed by "various other classes". Let me show you an alternative that is more ...
11
SQL is a detail. Knowledge of a detail should not spread.
As SQL is used in more and more places in your code your code becomes more and more dependent on it.
As you learn more and more SQL tricks you solve more and more problems using SQL. This means that switching to another API to persist involves more than just translating. You have to solve problems ...
10
Entity component systems (ECSs) can be programmed in an OOP or functional manner depending on how the system is defined.
OOP way:
I have worked on games where an entity was an object composed of various components. The entity has an update function which modifies the object in place by calling update on all its components in turn. This is clearly OOP in ...
10
What you can do is to create a factory, MainFactory that returns an instance of ConcreteMain as IMain.
Then you can inject this Factory into your Runner constructor.
Create the Main with the factory and pass inn itself as a parameter.
Any other dependencies on the ConcreteMain constructor can be passed into the MyMainFactory via IOC and pushed to the ...
10
Sounds like you have 3 major categories of data you are trying to store:
General job data (job id, job requester id, job receiver id etc)
State transitions (job started, job finished)
State-specific job data
(optional) job-related events (price changed, job receiver user reassigned etc)
The key is to separate event-like data from everything else.
Schema ...
10
CQRS is more of a data management thing rather than and doesn't tend to bleed too heavily into an application layer (or Domain if you prefer, as it tends to be most often used in DDD systems). Your MVC application, on the other hand, is a presentation layer application and should be fairly well separated from the query/persistence core of the CQRS.
Another ...
9
Yes, the service layer is an overhead if you don't have any business logic there. Layered architecture looks like an overhead when a layer (in your case service) is not doing much. But a layered architecture provides your loose coupling which is generally good for adapting requirements in future.
If you can guarantee that you will never need to do anything ...
Only top voted, non community-wiki answers of a minimum length are eligible
