6
You could do it that way, but I sense issues.
First, What if a user is both an Admin, and a MIS? It might not seem like it now, but eventually your organisation will generate a cross-functional individual.
Second, Your current design is a good breeding ground for breaking LSP. How does the page (which knows Employee) call the special administrative ...
5
I was thinking to expose some Interfaces in a contracts/interfaces
package in such a way that specific classes such as Record and
DataStorage would implement them and there wouldn't be a circular
dependency anymore.
This is fine. Each package defines (in the more abstract way possible1) the inputs and outputs so the dependency upon these packages is ...
4
There are use cases for both exceptions and result objects, so "cleanliness" of the code is dependent upon the use case. It all depends on how critical it is to stop the execution of the program.
Exceptions are the hand grenades of programming. Pull the pin and throw it. The only thing to keep your application from blowing sky high is to catch it and handle ...
3
the recommendation is to prefer returning a result object than
throwing an exception
This is bad advice IMHO, because they should be used in different circumstances. Using a result object when an exception is most appropriate is bad.
If ValidateUserInput is not able to perform its task because (for example) the process is out of memory, then throwing an ...
3
Basically both of the articles you reference are wrong. You should use enums where you have an enum.
You should also have change control on your database. If you bypass your change control processes for your code you can add an enum value, recompile the code on your desktop machine, RDP to the server and copy the binaries over the top of the application and ...
2
It should be on a case-by-case basis but I would expect most of the logic to go in the backend.
Your interactor might still contain several methods ("Check ticket availability", "Add ticket to basket", "Checkout") but yes the implementation could be expected to be very simple in some cases.
You might want to consider:
Security. Any code that you need to ...
2
Options:
1) The users can upgrade or hang. The Version 1.X is going out of support on the Xth of the Yth.
2) Support both lines going forward. I cannot recall the product at the moment though my memory is twigging a post by Joel somewhere. There is a company that designed a solution to a problem 3 times. They built V1, learned rebuilt it as V2, then when ...
2
What comes to mind is Levenshtein distance algorithm. It computes the number of changes (insertions, deletions or substitutions) needed to transform one array into another. It is used in general to compare strings (not just to know if a string is equal or not to another one, but how close a string is to another), but can be adapted for virtually any array (...
2
There is no strict definition of the term "back end".
Wikipedia defines the separation between front end and back-end as
"separation of concerns between the presentation layer (front end), and the data access layer (back end) [...], or the physical infrastructure or hardware"
But this is just a rule of thumb, so what you call front end and what you ...
2
Thoughts
Consider caching the full result set from the geo-spatial search.
You have a redis, so... it could go there. Now when the person requests the next page, there is a list tied to that location. You can page from that. You would still need de-dupping in the client for when redis drops the list.
Even better you could cache to the (location,page index)...
2
With enums this is fairly easy. We would just perform a very natural check if (cardType == CardType.Visa). The point is: the values are all there on code to be checked.
If you are using a CardType class and there is some behavior that has to be different from one instance to another, then allow the CardType object to know it. So, if there are two ways of ...
2
So it sounds like you want to implement some sort of access control.
You suggest to give each user one specific type and then creating a module per type that has the features that type needs.
While this can work, it will most likely lead to a lot of duplication. For example, in a webshop, "guest", "registered user" and "admin" can all "view index", "view ...
2
Methods which throws exceptions are not "honest". You can't recognize if a method is expected to fail or not, by looking at its signature.
Compared to [older versions of] Java this was argued to be one of .Net's biggest failings. Java laces Exceptions right into the Method signature; .Net doesn't.
Exception handling adds a lot of boiler plate code.
...
2
Software engineering is always a series of trade-offs. You have to give up something to get something else. The unfortunate reality is that we don't always have a full picture of what the impacts are on our system when we start. You've mentioned many principles here, so it makes sense to summarize the idea behind it.
Don't Repeat Yourself (DRY)
Bottom ...
1
Your reasoning on creating the TaskLog as a separate aggregate is correct and makes sense.
The responsibility of raising an event lies with the business logic, so prima facie, Option 1 would be the best choice. You would come close to this code structure if you follow DDD anyway, with a Task Application Service, Task Aggregate, and a Task Repository.
But ...
1
The standard way to do this is to use a STUN server to arrange a peer to peer connection and in cases where the topology of the network does not allow direct peer to peer connection, then use TURN to relay the connection via the TURN server.
1
This depends on a few things, maybe more but these are what I can think of off the top of my head.
Is your repository responsible for Async or are you going to treat it as sync.
Are you ok with stringing Rx through your entire application.
Both of these are sort of a matter of personal opinion and have tradeoffs to consider.
For example, in 1. Using Rx ...
1
You're dealing with a symmetric relation.
There are a number of ways for modeling symmetric relationships, and here's a third approach for you adapted from here.
CREATE TABLE people (
person_id int IDENTITY(1,1) PRIMARY KEY,
...other columns...
)
CREATE TABLE matches (
match_id int IDENTITY(1,1) PRIMARY KEY,
...other columns, if any...
...
1
The very definition of the terms "front end" and "back end" comes from the separation of business logic (back end) from the user interface (front end). So yes, business logic should be in the back-end, whether that is a remote service or simply a different layer in the same application.
Given that you already have a separate back-end system, you should ...
1
I think you should be careful about masking the cycle with interfaces.
I would recommend to let the storage know about the parser, but not the other way around. The parser seems to be your domain / business logic. Everything else revolves around it. Also see The Onion Architecture.
You can create a new package that orchestrates everything (e.g. app). But ...
1
I have never seen any pattern or variation that wasn't just a shell game.
Fundamentally, you have two writes that you are trying to commit
An update to the event bus (really, an update to the durable store of the event bus)
An history in your own durable store
Because these writes are fundamentally using two different locks, there's always going to be ...
1
Why not let a third "DatabaseLoggger" service update the database? So there will be only one app writing to the database, and none of the other apps is coupled directly to the db. All those other apps will have to send logging events to the service.
1
You can use a P2P network, but it's architecturally interesting.
Using something like Kademlia as a DHT for peer discovery means talking to a limited number of nodes before reaching your target. If you stored your message at each of these hops, you'd have redundancy for your message store that may be reliable enough for your requirements. Offline delivery ...
1
I know this question is from some years ago, but I've been dealing with a similar modelling problem at the moment, and perhaps it will be useful to someone else to see what alternative opinions are out there.
You're right, this section is a bit misleading and contradictory, as so much time is spent in DDD indicating that the domain design shouldn't be ...
Only top voted, non community-wiki answers of a minimum length are eligible
