More on this book
Community
Kindle Notes & Highlights
Many of us have been taught to believe that the database is inextricably connected to the business rules. Some of us have even been convinced that the database is the embodiment of the business rules.
But, as we shall see in another chapter, this idea is misguided. The database is a tool that the business rules can use indirectly.
is that translation code that knows about the BusinessRules.
They fail to realize a critically important principle: The IO is irrelevant.
Taken together, these two decisions about the database and the GUI create a kind of pattern for the addition of other components. That pattern is the same pattern that is used by systems that allow third-party plugins.
Indeed, the history of software development technology is the story of how to conveniently create plugins to establish a scalable and maintainable system architecture.
The core business rules are kept separate from, and independent of, those components that are either optional or that can be implemented ...
This highlight has been truncated due to consecutive passage length restrictions.
We want certain modules to be immune to others. For example, we don’t want the business rules to break when someone changes the format of a web page, or changes the schema of the database. We don’t want changes in one part of the system to cause other unrelated parts of the system to break. We don’t want our systems to exhibit that kind of fragility.
If the GUI plugs in to the business rules, then changes in the GUI cannot affect those business rules.
Boundaries are drawn where there is an axis of change.
The components on one side of the boundary change at different rates, and for different reasons, than the components ...
This highlight has been truncated due to consecutive passage length restrictions.
you arrange the code in those components such that the arrows between them point in one direction—toward the core business.
When a high-level client needs to invoke a lower-level service, dynamic polymorphism is used to invert the dependency against the flow of control. The runtime dependency opposes the compile-time dependency.
Communications between components in a monolith are very fast and inexpensive.
Remember that the architectural goal is for lower-level processes to be plugins to higher-level processes.
Communication across local process boundaries involve operating system calls, data marshaling and decoding, and interprocess context switches, which are moderately expensive. Chattiness should be carefully limited.
The strongest boundary is a service. A service is a process, generally started from the command line or through an equivalent system call. Services do not depend on their physical location.
Communications across service boundaries are very slow compared to function calls. Turnaround times can range from tens of milliseconds to seconds. Care must be taken to avoid chatting where possible. Communications at this level must deal with high levels of latency.
Most systems, other than monoliths, use more than one boundary strategy. A system that makes use of service boundaries may also have some local process boundaries. Indeed, a service is often just a facade for a set of interacting local processes.
Software systems are statements of policy.
computer program is a detailed description of the policy by which inputs are transformed into outputs.
Part of the art of developing a software architecture is carefully separating those policies from one another, and regrouping them based on the ways that they change.
Policies that change for the same reasons, and at the same times, are at the same level and belong together in the same component.
Note that the data flows and the source code dependencies do not always point in the same direction. This, again, is part of the art of software architecture. We want source code dependencies to be decoupled from data flow and coupled to level.
Critical Business Rules, because they are critical to the business itself, and would exist even if there were no system to automate them.
A use case describes application-specific business rules as opposed to the Critical Business Rules within the Entities.
This is very important. Use cases do not describe how the system appears to the user. Instead, they describe the application-specific rules that govern the interaction between the users and the Entities. How the data gets in and out of the system is irrelevant
Entities have no knowledge of the use cases that control them. This is another example of the direction of the dependencies following the Dependency Inversion Principle.
Why are Entities high level and use cases lower level?
Because use cases are specific to a single application and, therefore, are closer to the inputs and outputs of that system.
Entities are generalizations that can be used in many different applications, so they are farther from the in...
This highlight has been truncated due to consecutive passage length restrictions.
Use cases depend on Entities; Entities do not dep...
This highlight has been truncated due to consecutive passage length restrictions.
Use cases expect input data, and they produce output data. However, a well-formed use case object should have no inkling about the way that data is communicated to the user, or to any other component.
This lack of dependencies is critical. If the request and response models are not independent, then the use cases that depend on them will be indirectly bound to whatever dependencies the models carry with them.
The business rules should be the most independent and reusable code in the system.
Architectures are not (or should not be) about frameworks. Architectures should not be supplied by frameworks. 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.
Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and environments. Again, consider the plans for a house.
good software architecture allows decisions about frameworks, databases, web servers, and other environmental issues and tools to be deferred and delayed. Frameworks are options to be left open. A good architecture makes it unnecessary to decide on
Often they assume an all-encompassing, all-pervading, let-the-framework-do-everything position. This is not the position you want to take.
Develop a strategy that prevents the framework from taking over that architecture.
Your architecture should tell readers about the system, not about the frameworks you used in your system.
systems that have the following characteristics:
Independent of frameworks. The architecture does not depend on the existence of some library of feature-laden software. This allows you to use such frameworks as tools, rather than forcing you to cram your system into their limited constraints.
Testable. The business rules can be tested without the UI, database, web server, or any other external element.
Independent of the UI. The UI can change easily, without changing the rest of the system. A web UI could be replaced with a console UI, for example, without changing the business rules.
Independent of the database. You can swap out Oracle or SQL Server for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
Independent of any external agency. In fact, your business rules don’t know anything at all about the interfaces to the outside world.
the Dependency Rule: Source code dependencies must point only inward, toward higher-level policies.
Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle.
That includes functions, classes, variables, or any other nam...
This highlight has been truncated due to consecutive passage length restrictions.
