Chapter 11 - Systems

Main point of chapter is separation of concerns.
- In particular separating the build and config aspect of the application from the runtime logic.
It is common to see these tasks done together, which has some benefits but it breaks our single responsibility principle and makes the function most likely impure.

Allow us to separate our concerns by inverting dependencies.
We can have our build code create an implementation and then on the runtime side of the boundary we can have an interface which allows runtime parts of the application to interact with with what they need via the interface.
Dependency Inversion allows us to not mix dependencies across a boundary.

Is the application of Inversion of Control to dependency management.
Inversion of Control is a principle where a component receives its dependencies externally, rather than creating them itself.
True DI has a class which takes no steps to resolve dependencies.
- Provides setters to inject the dependencies.
- During construction, the DI container will use these dependencies.
- A DI container is a class that can instantiate and configure objects.

Systems need to be able to evolve over time as requirements change.
"Software systems are unique compared to physical systems. Their architectures can grow incrementally, if we maintain the proper separation of concerns."

Enterprise JavaBean is a platform for building reusable, portable and scalable business applications in Java.
- A server-side software component that encapsulates the business logic of an application.
An example of a bean is an Entity Bean, which is an in-memory representation of relational data.

You want to persist objects using the same strategy (naming conventions, file structure, etc...)
In practice, you spread similar code which implements the persistence strategy across many objects... this is where cross-cutting concerns comes in.
EJB's architecture anticipates aspect-orientated programming (AOP)
AOP: a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns.cross-cutting concerns like logging or security are separated from the core logic of the program, allowing them to be modularized and applied uniformly across different parts of the codebase without cluttering the main business logic.

Decoupling architecture concerns allows us to test drive architecture
Not necessary to do Big Design Up Front (completing the program's design and perfecting it before the actual implementation begins)
This means we can start projects with 'naively simple' (but decoupled) architecture
Still require some general expectations of scope (avoid scope creep, use mvp), goals, and a project schedule

We know it is best to give responsibilities to the most qualified person.
It is also best to postpone decisions until the last possible moment.
"The agility provided by a POJO system with modularized concerns allows us to make optimal, just-in-time decisions, based on the most recent knowledge. The complexity of these decisions is also reduced".

"Standards make it easier to reuse ideas and components, recruit people with relevant experience, encapsulate good ideas, and wire components together. However, the process of creating standards can sometimes take too long for industry to wait, and some standards lost touch with the real needs of the adopters they are intended to serve".

DSL: Separate, small scripting languages or API's in standard languages.
Permit code to be written in a structured form.
When used correctly, raise the abstraction level above code idioms and design patterns.