I write about models importance quite often (maybe I’ll provide translation to my previous polish-only posts). But models are important, and I found confirmation that isn’t just my imagination. It was found in a book I actually read:

Agile Web Development with Rails, Third Edition

There’s a interesting paragraph about model layer:

A model is more than just data; it enforces all the business rules that apply
to that data. For example, if a discount shouldn’t be applied to orders of less
than $20, the model will enforce the constraint. This makes sense; by putting
the implementation of these business rules in the model, we make sure that
nothing else in the application can make our data invalid. The model acts as
both a gatekeeper and a data store.

Jeśli masz w jakikolwiek sposób do czynienia z wytwarzaniem oprogramowania to mam dla Ciebie naprawdę dobrą książkę.
Sprawne zarządzanie projektami metodą Scrum

Jeśli metodyka używana aktualnie u Ciebie w firmie Cię męczy, jest to typowy waterfall i czujesz, że nie do końca pasuje- w tej książce znajdziesz ciekawe przypadki opisujące podobne problemy.
Jeśli jesteś managerem, albo właścicielem firmy i wydaje Ci się, że nie ma nic lepszego niż model wodospadowy – na prawdę ta książka może Cię zainteresować. Być może po jej lekturze inaczej spojrzysz na swoją firmę.

Nawet jeśli jesteś grafikiem, które kwestie techniczne zleca “zewnętrznej firmie” – książka ta pozwoli Ci inaczej spojrzeć na tą współpracę. Bardzo możliwe też, że zaczniesz dostrzegać problemy, których istnienia nie do końca zdawałeś sobie sprawę. A to pierwszy krok do ich usunięcia.

Sam czytałem tą pozycję i stwierdzam, że wbrew pozorom nie jest przeznaczona tylko dla programistów:

W momencie, kiedy aplikacje stały się bardziej skomplikowane, a ilość udziałowców projektu wzrosła, w celu koordynacji komunikacji między zwiększającą się liczbą uczestników zaczęto stosować pewne zasady. Na przykład, ze względu na dużą ilość zaangażowanych udziałowców, zaczęliśmy zbierać wymagania przed rozpoczęciem tworzenia oprogramowania.

To jest pierwszy krok do modelu waterfall. Dodając do tego szczyptę problemu z ustalaniem kontraktów, które mogą wyglądać tak:

Jeśli zgadzacie się, że to co wam pokazałem jest pełnym opisem waszych wymagań, będziemy kontynuować. Jeśli się nie zgodzicie, będziemy kontynuować dopracowywanie wymagań do momentu, aż się poddacie.

… i jako efekt K. Schwaber celnie trafia w sedno:

Każdy kolejny krok tworzył coraz to większą przepaść między udziałowcami i programistami. Przeszliśmy od komunikacji twarzą w twarz do tworzenia dokumentacji. (…) Z perspektywy czasu, im bardziej ulepszaliśmy praktyki inżynierii oprogramowania, tym bardziej poszerzaliśmy przepaść między udziałowcami a programistami. Ostatnim etapem separacji było wprowadzenie metodologii kaskadowej, która wciela w życie wszystkie wady programowania sekwencyjnego.