Use case realization is the set of class diagrams and interaction diagrams that implement a use case
Data model that can be changed to domain model
There is no such thing as a "correct" list. It is a somewhat arbitrary collection of abstractions and domain vocabulary that the modelers consider noteworthy
Fact: Each responsibility is an axis of change. Reminder: We must agree that if a change occurred on a class, then all the dependencies must be: Rebuild Retest Redeploy Because we have many responsibilities then we have many reasons to change which means a huge rebuild, retest and redeploy for all the clients
Geometric Rectangle has less reasons to change which means less probability to change the class. But if you are sure it will change, then use Design Patterns (Strategy design pattern)
LSP violation means you need to re-design your abstractions hierarchy.
Through the discussion of SOLID principles, we show some useful principles to apply through the design by showing classes with problems and solving them; but we didn’t show how did we get these classes and how did we assign their responsibilities. In the following section we will talk about how to find the responsibilities and how to assign the proper responsibility to the proper class.