In my workplace, we have an intranet website developed internally that we use for CRM. The data of our clients are shown there (MS SQL server is used as a backend to store data). The site has a limited search functionality at the moment (it'll try to match the text you type in one of the 3 fields that are indexed -company, staff contact, and director name).
I'm trying to find info about what would be the easiest method to implement a more sophisticated search (ideally that makes use of AI), like the one implemented by Google or Amazon on their website. It doesn't have to be so sophisticated, anything better than what I described above would do it. Ideally, the search should be able to guess what you're looking for based on your role, your portfolio of clients, and previous searches. It would be great if it could understand what you mean (i.e search query 'song la la la' that returns as result 'ATC -All around the world' on youtube. It would be great to implement vocal search as well.
But again it doesn't have to be that complex. Any info on where to look or which resources are readily available would be greatly appreciated. Do you know if there are (and what would be the best) search engines/AI libraries/API that are open source and that would fit this purpose? If this is not the right place to ask, on which other website or forum do you think should I ask for?
Then why are you thinking about architecture patterns. Get you business plan and requirements sorted and THEN start looking into what platform(s) you will service and the different patterns that will meet your requirements.
Never underestimate the power of human stupidity -
I'm old. I know stuff - JSOP
Many patterns, such as those in the GoF book, aren't "architectural". They're more tactical, although they can help to make an architecture better.
Jim Coplien, who was well-known in the C++ world, got involved with patterns early on. Later, he said that there was too much focus on patterns. The emphasis needs to be on encapsulation, polymorphism, and inheritance. Patterns are the exception when those things, by themselves, don't produce loosely coupled code.
To understand a pattern, you need to have seen what code looked like before the pattern was applied, and after. Then, when you write or find code that looks like the "before" code, you'll know how the pattern can improve it. That's usually how a pattern gets used. How code evolves to satisfy its specifications is what determines which patterns are used; it is wrong to start out by saying which patterns will be used before you have a good sense of the high-level design.
Poorly considered, but it fits well within the current software engineering zeitgeist, so it makes sense that it would get written. That's the fancy way to say: "it's a fad, don't worry about it". And stop reading Uncle Bob.
"it's not flexible", not if you consider adding an extra case to be a Big Deal, but the alternative is adding an entire new class.
Even if you are of the opinion that creating new classes is somehow easier than creating new cases, then spend a little time thinking about what would happen when the function signature of that virtual function is changed, or if something about the API used by the subclasses to implement themselves changes. This has the annoying property that the fix you're about to write is highly non-local, you'd have to "hunt down" all the places that need to change - in the best case they correspond to compile errors.
If a requirement is broken into N cases, but the code is spread out non-locally over N classes, your code does not look like the requirement which makes it harder to check whether it matches.
"it's not SOLID", maybe, but SOLID is subjective and overrated.
"horrific", let's not even talk about it.
The presented "better way" presupposes that we have a convenient instance of the "class that represents a particular reason". How did we get that? Chances are that there's a switch hiding in a factory pattern or something. Moving the problem. And if there is some pattern such as new AddressChanged().Update(), how about we don't wrap it in a class and just call a method that does that.
Article forgets to point out that in the first place the only domain that was considered is the business logic domain. Even if it makes sense there (which I don't agree with either), it won't make sense anywhere else. There's no way Math.Min would have its if replaced by polymorphism.