to communicate with the cook, but it gives the cook less to remember because he’s got all the diner patterns in his head. • Once you’ve got the vocabulary you can more easily communicate with other developers and inspire those who don’t know patterns to start learning them. • It also elevates your thinking about architectures by letting you think at the pattern level, not the nitty-gritty object level.
stakeholders. 2. Encourage separation of concerns. 3. Run away from the real world (Android, DB, Internet etc). 4. Enable your components to be testable.
be object with methods or set of data structures and functions. • Encapsulate most general and high level rules. • Least likely to change when something external changes (like page navigation, security etc). • For News app like NYT, entities would be Category, Article, Commercial etc.
Encapsulates all use cases of the system. • Orchestrate data flow to and from entities. • Doesn’t change with entities or externalities (UI, DB etc). • However, changes to operation of application will affect the use cases. • Ex. Transfer money from one account to another will be “TransferMoneyUseCase”.
from format convenient to use cases/entities to a format convenient to an external agency (UI, DB, Web etc). • Contains MVC architecture of a GUI (Presenters, Views, Controllers etc). • Models are just data structures that are passed from controllers to use cases and then back from use cases to presenters and views.
etc. • We only write the glue code here which binds the inner circles. • Details go here (UI, DB, Web etc). These are kept outside where they can do little harm.
inwards. Dependency Inversion Principle: We would arrange interfaces and inheritance relationships such that the source code dependencies oppose the flow of control at just the right points across the boundary.