Hot answers tagged

10

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


6

The "right" answer would almost always have edges authenticate with some sort of user account or other auth mechanism. Why? Because you can limit access of that specific edge interface to only the data they need with the right scopes. For example, a worker only updates orders but can't see payment info. If there was a compromise of the worker it can't ...


5

Is there any advantage here that I am missing? Yes, there is. I, along with a large number of software projects, used to follow the practice outlined in the question. Many projects, including modern ones I work on, now take the opposite approach in a source file: The header file that declares the functions being defined in the source file is the very ...


3

Onion architecture is one of the possible choices when you use DDD. If you decide to use it, the implementation should be in the infrastructure layer. You can have several implementation of the same interface and inject the required one in your application. IMO the interfaces themselves should be in the Domain layer.


3

You are trying to create a layered design. In the top layer are inputs & outputs that interact with the elevator riders: the inputs are the button panel in the elevator and the displays of what floor it's on along with the up/down indicator and button pressed indicators. Further there are up/down call buttons on each floor (and a duplication of the ...


3

Here is how I design similar system : Client : ios/Android/other mobile clients interact with my API to make some orders or view orders API : Backend Restful service which handles the requests from clients and UI. If the orders need to be processed asynchronously then we should use Queues, from the question I get that the orders are handled asynchronously....


2

For the sad "Messy DBs" part I recommend a book by Scott Ambler "Database Refactoring", it teaches you a lot about the real world of databases, and no, it sure will not save you from SQL, but it might save your product's life, i.e. get it to a maintainable state. don't fear the SQL, master it (TSQ, PL/SQL and other native DB languages) And EF, a few ...


2

I tend to find it a good idea to use a mapping at each point of conversion, yes. While maybe a hair more work to start, it tends to keep things from having to be split later and nicely isolates functionality into the context areas that it really belongs. Who's to say that a year down the road your external API source won't change? Easier at the outset I ...


2

One app code base, one database schema, but probably run the apps separately and have the dbs use the same schema actually be different db instances. Don't design for it now, but you could imagine that if you need communication between these guys you could expose an api and have another service handle something like that, so a monolithic app is eh. You ...


1

To put all the applications in one solution is to say that all of the applications are related somehow. If they aren't, don't put them in the same solution. What you really are after is code-reuse. Since you don't specify a technology stack I'll list out some options in multiple technologies. These allow you to share code without stuffing applications ...


1

Depends on what your interface returns. Assuming they return domain entities they should go in your domain layer. The actual interface implementations can go in your persistence layer. When you have your repository interfaces in the domain layer the layers above does not depend on your persistence layer. From a conceptual standpoint the idea that you get "...


1

It looks like your system has a producer-consumer scenario, where one part produces data/message for other part to consume it. If it is so, you can well utilize a Message Broker like MSMQ or RabbitMQ. Since they allow asynchronous communication between two applications. Whether it is feasible for your system or not would depend upon it's complexity, ...


1

Note: The top part of this answer is an answer to the question before the view-example has been posted by the original poster. For an updated version, taking the view in mind, check the bottom of this answer, under the line. I don't like you passing a query to a database abstraction layer actually covering two databases. An abstraction layer dealing ...


1

Most usually yes. In fact, it's usually the simplest solution, because the authentication and authorization mechanisms need to be built and tested anyway. And, I'd argue for it being the default solution unless compelling reasons surface to bypass the normal auth* rules. The alternative is to add another set of authentication and authorization modules, ...


1

The reason it hasn't been answered is that it appears to be mixing different levels of abstraction. It is common to have different categories of users. In this case I see three categories of users of the API: Web App Client (may use different interfaces than the Web App) Workers (may access the APIs using a Web App or client) It may be better to ...


1

I've always had the fleet of workers interact directly with the database (or queue, whatever has the order state), which might simplify access. But in logs, you want to make sure you can name and trace back to workers, for auditing an order flow. Also, you need to synchronize the workers doing work, and clients grabbing state via the API. If you have a ...


1

I would go this way: This uses a service to expose all of the bussiness functionality. Then, your MVC app could grab all the data returned from a service a create a View with it, while the API would use the same service to return JSON/XML. Your MVC app and you API would then have the same funcionality and you mobile app could grab whatever info is needed ...


1

Each microservice should not have to do its own authentication, but it does need to do its own authorization. Source And this makes perfect sense. I'm assuming there is no doubt about central authentication. But authorization is pretty confusing. Considering that number of micro-services can grow upto hundreds, thousands, A central authorization service ...


1

The other end of the spectrum from the fat service class is the use of commands and a command processor. Basically each of your service methods is broken off into its own command. This article by Ian Cooper gives a good description of refactoring from a fat service to commands: Why use the command processor pattern in the service layer Some of the ...



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