Wprowadzenie bardzo często mozna spotkać opisu typu: MVC architecture. AngularJS divides your web app into three distinct parts — Model (data), View (the UI layer), and Controller (business logic). The three units can be developed in parallel and separately tested. As a result, the code becomes easier to understand, maintain, and extend. (https://www.altexsoft.com/blog/the-good-and-the-bad-of-angular-development/) Niestety jest to powielanie podejścia z czasów lat 90-tych i JavaEE/SE. Patrząc na te trzy pojęcia View to owszem "widoki" czyli GUI, nieporozumienia dotyczą Model'u i Controler'a. Poniżej obecne źródło (jedno z wielu) tego nieporozumienia: Model to…
zły model to złe oprogramowanie....
Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą [[Martina Fowlera]]: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią.
Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną "obsłużone".
