Skip to content

Systems

How Would You Build a City?

Divide the system in appropriate levels of abstraction and modularity that make it possible for individuals and the “components” they manage to work effectively, even without understanding the big picture.

Separate Constructing a System from Using It

Software systems should separate the startup process.

Separate startup Process with runtime logic.

Separation of Main

Separate construction from use is simply to move all aspects of construction to main , or modules called by main , and to design the rest of the system assuming that all objects have been constructed and wired up appropriately.

Factories :

use the ABSTRACT FACTORY pattern to give the application control of when to build the LineItems , but keep the details of that construction separate from the application code.

Dependency Injection

Scaling Up

write methods as small as possible if any new update will come we can extends that feature.

Software systems are unique compared to physical systems. Their architectures can grow incrementally, if we maintain the proper separation of concerns.

Cross-Cutting Concerns

Use aspect-oriented programming (AOP) to restoring modularity for cross-cutting concerns.

Modularity give more flexible to find bugs.

  • Java Proxies: Use AOP instead of proxies.
  • Use Pure Java AOP Frameworks.
  • use AspectJ Aspects.

    • Test Drive the System Architecture

    The power of separating concerns through aspect-like approaches can’t be overstated.

    If you can write your application’s domain logic using POJOs, decoupled from any architecture concerns at the code level, then it is possible to truly test drive your architecture. as needed, by adopting new technologies on demand.

    Optimize Decision Making

    Modularity and separation of concerns make decentralized management and decision making possible.

    Use Standards Wisely, When They Add Demonstrable Value

    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 lose touch with the real needs of the adopters they are intended to serve.

    Systems Need Domain-Specific Languages

    DSL minimizes the “communication gap” between a domain concept and the code that implements it.

    If you are implementing domain logic in the same language that a domain expert uses, there is less risk that you will incorrectly translate the domain into the implementation. So Use Domain Specific Language .