More on this book
Community
Kindle Notes & Highlights
by
Evans Eric
Started reading
December 20, 2016
tongue in cheek,
Therefore, when circumstances warrant: Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available.
fact, it is difficult to apply any of the methods discussed later in this book without that separation, and so this SMART UI can be considered an “anti-pattern” in the context of domain-driven design. Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common.
Productivity is high and immediate for simple applications. • Less capable developers can work this way with little training. • Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests.
Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately. Expanding the system with additional, simple behavior can be easy. • Relational databases work well and provide integration at the data level. • 4GL tools work well. • When applications are handed off, maintenance programmers will be able to quickly redo portions they can’t figure out, because the effects of the changes should be localized to each particular UI.
Integration of applications is difficult except through the database. • There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply. • Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options. • Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.
The SMART UI is discussed only to clarify why and when a pattern such as LAYERED ARCHITECTURE is needed in order to isolate a domain layer.
If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven design.
If you have a complex application and are committing to MODEL-DRIVEN DESIGN, bite the bullet, get the necessary experts, and avoid the SMART UI.
Connecting model and implementation has to be done at the detail level.
associations.
Does an object represent something with continuity and identity—something that is tracked through different states or even across different implementations? Or is it an attribute that describes the state of something else? This is the basic distinction between an ENTITY and a VALUE OBJECT.
A SERVICE is something that is done for a client on request.
every design decision should be motivated by some insight into the domain.
The ideas of high cohesion and low coupling, often thought of as technical metrics, can be applied to the concepts themselves. In
MODULES are part of the model, and they should reflect conc...
This highlight has been truncated due to consecutive passage length restrictions.
For every traversable association in the model, there is a mechanism in the software with the same properties.
There are at least three ways of making associations more tractable. 1. Imposing a traversal direction 2. Adding a qualifier, effectively reducing multiplicity 3. Eliminating nonessential associations
Understanding the domain may reveal a natural directional bias.
It captures the understanding that one direction of the association is much more meaningful and important than the other.
focalidade da direcao do relacionamento
This qualifier reduces the multiplicity to one-to-one,
Consistently constraining associations in ways that reflect the bias of the domain not only makes those associations more communicative and simpler to implement, it also gives significance to the remaining bidirectional associations.
the ultimate simplification is to eliminate an association altogether, if it is not essential to the job at hand or the fundamental meaning of the model objects.
but whatever the particular rules, as constraints on associations are discovered they should be included in the model and implementation.
They make the model more precise and the implementation easier to maintain.
Many things are defined by their identity, and not by any attribute.
Am I the same person I was at age five? This kind of metaphysical question is important in the search for effective domain models. Slightly rephrased: Does the user of the application care if I am the same person I was at age five?
A conceptual identity has to be matched between multiple implementations of the objects, its stored forms, and real-world actors such as the phone caller.
the fundamental concept of an ENTITY is an abstract continuity threading through a life cycle and even passing through multiple forms.
An object defined primarily by its identity is called an ENTITY.
not all objects in the model are ENTITIES, with meaningful identities.
Consider transactions in a banking application. Two deposits of the same amount to the same account on the same day are still distinct transactions, so they have identity and are ENTITIES. On the other hand, the amount attributes of those two transactions are probably instances of some money object. These values have no identity, since there is no usefulness in distinguishing them.
The model must define what it means to be the same thing.
Rather than focusing on the attributes or even the behavior, strip the ENTITY object’s definition down to the most intrinsic characteristics, particularly those that identify it or are commonly used to find or match it.
Add only behavior that is essential to the concept and attributes that are required by that behavior.
Beyond identity issues, ENTITIES tend to fulfill their responsibilities by coordinating the operations of objects they own.
crc
When the ID is automatically generated, the user may never need to see it.
Finally, there are cases in which a generated ID is of interest to the user.
Tracking the identity of ENTITIES is essential, but attaching identity to other objects can hurt system performance, add analytical work, and muddle the model by making all objects look the same.
Software design is a constant battle with complexity. We must make distinctions so that special handling is applied only where necessary.
VALUE OBJECTS are instantiated to represent elements of the design that we care about only for what they are, not who or which they are.
“Address” a VALUE OBJECT? Who’s Asking?
VALUE OBJECTS are often passed as parameters in messages between objects.
They are frequently transient, created for an operation and then discarded. VALUE OBJECTS are used as attributes of ENTITIES (and other VALUES).
When you care only about the attributes of an element of the model, classify it as a VALUE OBJECT. Make it express the meaning of the attributes
In large systems, this kind of effect can be multiplied by thousands, and such an optimization can make the difference between a usable system and one that slows to a crawl, choked on millions of redundant objects. This is just one example of an optimization trick that is not available for ENTITIES.
Many of the distinctions we are making in the model cannot be explicitly declared in the implementation with most current tools and programming languages.
When a VALUE OBJECT is designated immutable in the design, developers are free to make decisions about issues such as copying and sharing on a purely technical basis, secure in the knowledge that the application does not rely on particular instances of the objects.
Avoiding unnecessary constraints in a model leaves developers free to do purely technical performance tuning.
This technique of storing multiple copies of the same data is called denormalization and is often used when access time is more critical than storage space or simplicity of maintenance.
