Quotes About Design

The source code of higher-level services must not contain any specific physical knowledge (e.g., a URI) of any lower-level service.

Architects separate functionality based on how, why, and when it changes, and then organize that separated functionality into a hierarchy of components.

THE ACYCLIC DEPENDENCIES PRINCIPLE Allow no cycles in the component dependency graph.

The goal of the architect is to create a shape for the system that recognizes policy as the most essential element of the system while making the details irrelevant to that policy. This allows decisions about those details to be delayed and deferred.

But then closely related concepts should not be separated into different files unless you have a very good reason. Indeed, this is one of the reasons that protected variables should be avoided.

If we tried to design the component dependency structure before we designed any classes, we would likely fail rather badly. We would not know much about common closure, we would be unaware of any reusable elements, and we would almost certainly create components that produced dependency cycles. Thus the component dependency structure grows and evolves with the logical design of the system.

A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat, or MySQL, until much later in the project. A good architecture makes it easy to change your mind about those decisions, too. A good architecture emphasizes the use cases and decouples them from peripheral concerns

The word "architecture" is often used in the context of something at a high level that is divorced from the lower-level details, whereas "design" more often seems to imply structures and decisions at a lower level. But this usage is nonsensical when you look at what a real architect does.

a good architecture must support: • The use cases and operation of the system. • The maintenance of the system. • The development of the system. • The deployment of the system.

The moral of the story is simple: Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

The business rules should be the most independent and reusable code in the system.

To build a system with a design and an architecture that minimize effort and maximize productivity, you need to know which attributes of system architecture lead to that end.

Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

More precisely, the Law of Demeter says that a method f of a class C should only call the methods of these: • C • An object created by f • An object passed as an argument to f • An object held in an instance variable of C

Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.

Master programmers think of systems as stories to be told rather than programs to be written.

The first concern of the architect is to make sure that the house is usable — not to ensure that the house is made of bricks.

Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work.

Databases should usually not be considered as a major factor of the design and implementation.

structured programming, object-orient programming, and functional programming.

During this design process, we rarely considered whether we were performing analysis, design, or implementation

Notice how well those three align with the three big concerns of architecture: function, separation of components, and data management.

What do we talk about when we talk about architecture?

Programming is an act of creation. When we write code we are creating something out of nothing. We are boldly imposing order upon chaos.