47
What makes you so special?
My CPU says it works and I want to go home. Why are you bothering me?
You can deal with this attitude by forcing everyone to issue pull requests. But now the deadlines are looming. Bad code presses on the gates of your pristine castle and you finally give in to the pressure. Or you win only to find everyone leaves and no one uses ...
19
First, get people to maintain things they didn't write. It's very easy for a developer to get into habits of using frameworks and techniques they are used to. It's jarring to have to switch between frameworks and methodologies. If someone is forced to move outside of their own corner of the code and experience that often, it will prompt some complaining ...
7
Your framework choices strongly influence the architecture your applications will have. Many of the architectural decisions have already been made by the framework for you, so trying to impose your own architecture over that would be like swimming against the current.
But this is kind of the whole point of choosing a framework. Developing a suitable ...
6
Perform code reviews every time someone wants to merge code into the main branch/trunk and hold people to those standards when reviewing the code.
And I don't mean that only you should perform the code reviews. Everyone should review everyone else's code. This disseminates knowledge about the system across the team but also creates a situation where Carol ...
6
You could split your application in "bounded contexts" (see Domain Driven Design) and use events to communicate between contexts. The events should only use simple data types that could be easily transferred over the wire later. Direct object references to another bounded countext wouldn't be allowed.
5
No.
Remember that it's not your application calling the API, it is Chrome or Edge or whatever browser is running the app. Once the code is on a user's machine they can exploit that to do whatever they want.
If you want to constrain access to an API you'll need to either require cryptographic keys or limit network access. Neither of which is viable if you ...
5
Yes, systems can have just one use case. That is quite normal for systems with very specialized, automatic tasks and no real user. This reveals, however, that for such kind of systems, "use case analysis" does not bring you much benefit (except from the result there is only one).
The purpose of this method is to split larger requirements into smaller ones,...
4
You've got options.
Bare Metal/Standard Virtual Machines
If you are on bare metal (getting rarer these days, but still common enough in some industries), you can always have an instance of your discovery service on each machine. Since just about all of them handle clustering, you just need to look at localhost for your discovery service.
Dockerization
...
4
Use environment variables. They've existed for decades and all current (and past) tools support it, including Docker, Kubernetes and the like.
4
Do I need related SQL tables (e.g. with the book metadata in one table and word data in another)
A separate table for words can be used, but it is probably not necessary. A "word" is identified by all of its letters, it has no additional metadata, and for your use case, you probably don't have the requirement to correct individual word spellings after the ...
3
The answer to your question from the title depends on the definition of "software architecture". One popular definition is: the design decisions which are costly to change at a later point time (at least not without a complete rewrite). So choosing a framework like DRF is an architectural decision.
However, from your question text, I guess you have a much ...
3
Your idea to use a service to hide the access control complexities is entirely valid. Doing it otherwise risks that the complex logic gets spread around and possibly duplicated and at the same time you would be violating the Single Responsibility Principle for the controllers.
With regard to where to put the domain knowledge of the access control, I am of ...
3
By loose interpretation, your application is the mediator. Essentially, you just need to encapsulate access to the service, and you need to encapsulate access to storage. Your application invokes the service and interprets the results, placing data in the storage component. So, adding a special class for the mediation might be overkill since your ...
3
The other answers are correct as far as the coupling being at the data interface level. But they don't really answer the question posed in the title:
How do I manage shared models among many microservices?
Conventional microservice wisdom is to err on the side of coupling loosely; share as little code as possible.
A brief overview of the problems with ...
3
As you've already surmised, a metric like "Attack Success Rate <= 0.001%" isn't a particularly useful test metric for an acceptance text.
Have a look at this page. It says:
Non-functional requirements
Security
Provider systems SHALL resist unauthorised, accidental or unintended usage and provide access only to legitimate users.
Please ...
2
There is no hard and fast rules how to handle errors. When an operation could (theoretically) produce an error, you need to look at the situation, each situation individually, and decide how to cope with it.
Case 1: Errors that you are convinced cannot happen. Check for them, and in a debug version have an assertion that will stop execution in the debugger,...
2
To add to what @deamon said do your vertical slices all the way to the database, don't use referential integrity, use Guids as primary keys, use fields and not entities...
Maybe this can help:
https://www.youtube.com/watch?v=-4s7ioADuCA
https://www.youtube.com/watch?v=yxjrObdWQow
Hope this helps :-)
2
NFR requires that all the responses should have measurable equation which is used by tester in verification phase.
I thinking this is probably the root cause of your issue. Some problems are just hard, and can't easily be reduced to a simple metric.
If your business truly cares about protecting its users' PII, the best thing to do is almost certainly to ...
2
One use case? Don't stop there. What about systems without a use case?
The ideal automated system has no use case. It just works. Anything that is used is semi-automatic at best.
Your refrigerator keeps your food cool. Puting your food in and taking it out is independent from the system's behavior, that is not a use case. The cooling part is totally ...
2
A design allowing A to throw messages on the message bus B reads strengthens the message passing abstraction. A design requiring B reading from A's cache might be more likely to produce a close coupling of A's and B's internals.
In a message passing implementation, if Topic 3 arrives first B leaves it in its mailbox. When Topic 1 arrives, B checks its ...
2
Your question is very broad, so expect only to get a broad answer.
The general strategy for solving these kinds of problems is to make the requirements customizable. This can be done by introducing run time or compile time switches, configuration files, special code which is only used for a specific customer, "plugins", and so on.
From what you wrote, in ...
1
This answer is based on the additional information from the comments.
If the database is part of your system then whenever other system requests those data, your system has to offer them (let's disregard for a moment how is it done - this is true also if other system reaches directly to the database1). So from perspective of your system if other system asks ...
1
Note: I'm going to answer the technical question as asked here. Depending on the role the interview is for, the correct interview answer may very well be "having a counter is stupid; there should be a time constraint or per-account limitation" (as Bart von Ingen Schenua appears to suggest in the comments).
Assumption: 500.000 isn't the exact maximum; 500....
1
I think you misunderstand the concept of 'Serverless' technology. IMO it's a very misleading and confusing name so you are not alone in this.
using JavaScript and APIs (serverless).
Using Javascript and APIs is not the definition of serverless. The client is not relevant at all to serverless technology. Here's a very in-depth article on serverless ...
1
Say each microservice is using event sourcing which means it has it's own event store, do you typically add another "mother" event store that contains all events from all microservices as a source of truth on how each system communicated?
No, but sort of.
Typically, separate micro-services means that any given stream has a single logical authority that "...
1
Can Aggregate shared between services?
The short answer is: no.
To ensure consistency, you normally want only a single authoritative representation of an aggregate. That will normally mean that the aggregate is "stored" in one place - for example, in "the database".
So in a way, sharing the authority for an aggregate is analogous to sharing a database ...
1
Q: My question is this: Is it better for performance or any other reason to host both the API and the SPA on the same origin?
It's not a matter of performance. Security and performance rarely get along. I would dare to say it's a matter of convenience. Organising applications under the same "umbrella" (domain) ease the handling of CORS, cookies and session ...
1
As Ewan mentioned, the two services are coupled by the data exchanged, not the model (from a strictly object oriented perspective). NOTE: I get a 404 when I follow your link, it looks like a private project.
From a web service perspective data is exchanged in a known schema. It could be XML or JSON, but that is less important than the structure of the ...
1
They are not coupled by the model.
They are coupled by the format of the data they exchange, which they deserialise to the model.
If they have to talk they have to understand each other. so yes its practically inescapable. Although in theory maybe you could write an AI which could interpret varying structures I doubt it would be easier than simply ...
1
Basically all should be packed as a transaction.
However, on a failure you might want to place the work in a state FAILED in order to prevent retries - as you sketched. I would say, that is a new second transaction (@TansactionAttribute (TransactionAttributeType. REQUIRE_NEW)), preferably done when the other transaction is still failing. Rolled back should ...
Only top voted, non community-wiki answers of a minimum length are eligible
