DDD

Question 1

What is the key to controlling complexity in software development?

Answer 1

A good domain model that goes beyond surface vision and introduce an underlying structure.

Question 2

Why should concepts not be separated from their implementation in domain modelling?

Answer 2

The greatest value a domain model provides a ubiquitous language that ties domain experts and technologists together.

Question 3

What is domain driven design in large strokes?

Answer 3

Its both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

Question 4

How does extreme programming view design?

Answer 4

It is important. But it resists upfront design. It rather puts effort into a project’s ability to change course rapidly. When we can change course rapidly we can settle with the simplest thing that could work, and then continuously refactor the solution. This is an antidote to analysis paralysis.

Question 5

What is a model?

Answer 5

A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information and focuses it on a problem.

A domain model is a rigorously organized and selective abstraction of the knowledge inside a domain experts head. Domain modelling is not a matter of making as realistic as possible, rather a loosely representation to a particular purpose.

Question 6

What is the heart of software?

Answer 6

Its ability to solve domain-related problems for its users. All other features support this basic purpose. Complexity at the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.

Question 7

What are the ingredients of effective modeling?

Answer 7

1. Binding the model and the implementation - crude prototype users can see and comment on.
2. Cultivating a language based on the model.
3. Developing a knowledge-rich model. The model was not just a data schema; it was integral to solving a complex problem. It captures knowledge of various kinds.
4. Distilling the model. Concepts are dropped from the model when they are not important or useful. A new model can be made to concepts that do not belong.
5. Brainstorming and experimenting.

Question 8

What role do prototypes and early versions play when modelling the domain?

Answer 8

Feed experience back into the team, change interpretations and validate hypothesis.

Question 9

What are the disadvantages of simply receiving a feature list from experts and just build them?

Answer 9

Developers only learn what the application should do and not the fundamental principles behind it. The application will never arrive at a point where powerful features unfold as corollaries to older features.

Question 10

Why can even what looks like a simple domain turn out complex?

Answer 10

Domain experts are usually not aware of how complex their mental processes are. They navigate a lot of rules, reconcile contradictions and fill in the gaps with common sense.

Question 11

What advantages are there to using an explicit model and design to model business rules?

Answer 11

1. In order to bring the design to this stage, the programmers and everyone else involved will have to come to understand the nature of the business rules as a distinct and important business rule, not just and obscure calculation.
2. Programmers can show business experts technical artifacts, even code, that should be intelligible to domain experts. Thereby, closing the feedback loop.

Question 12

What are the dangers of translation between domain experts and developers?

Answer 12

Translation muddles model concepts, which may lead to destructive refactoring of code. The indirectness of translations makes it hard to develop clear modules that need to fit together since developers and domain experts may interpret translation in their own way.

A project faces serious problems when its language is fractured (developers and domain experts do not understand each other).

Question 13

What is the vocabulary of a ubiquitous language ?

Answer 13

It includes that names of classes and prominent operations. The language includes terms to discuss rules that have been made explicit in the model.

With a ubiquitous language, the model is not just a design artifact. It becomes integral to everything the developers and domain experts do together.

Question 14

How is a ubiquitous language formed?

Answer 14

Cultivated in the intersection of jargons between developers and domain experts. Conversations between developers, discussions among domain experts and expressions in code are all based on the same language, derived from a shared domain model. That is updated and evolve over time as developers process information from domain experts and domain experts accept/protest interpretations of their information.

Question 15

What are the limits of code as a “design document/documentation”?

Answer 15

It can overwhelm the reader with detail. The behavior is not always obvious and the meaning/intention/reason for a behavior can be hard to convey.

Question 16

What is the problem with only using an analysis model (analyzing the problem domain to gain understanding)?

Answer 16

Some knowledge crunching happens during such analysis, but most of it is lost when coding begins, when developers are forced to come up with new abstractions for the design.

Question 17

What is the danger of viewing domain analysis and development as separate processes?

Answer 17

If we think of analysis and development as separate processes then the connection between the two will loosen and its impossible to maintain the relationship as the design changes. Additionally, developers might not have adequate access to domain experts.

Insights gained in the two do not feed into the other.

Question 18

What is the specification pattern?

Answer 18

The specification pattern is about encapsulating a piece of domain knowledge into a single unit (called specification) which we can then reuse during:
1. data retrieval
2. in-memory validation (controversial because of “always-valid model guideline”) but can be used to work on-top of valid objects to perform validations before performing certain domain operations.
3. creation of new objects
4. bulk updates, combined with a command that uses the preconditions from the specification.

Question 19

What is the command pattern?

Answer 19

The command pattern encapsulates the knowledge of how to update domain model data. But the term is overloaded a means different things in different contexts:
CQRS (command-query-responsibility-segregation): a command is a class that represents an operation.
CQS (command-query-separation): any method that creates a side effect.
GoF (Gang of Four): a command is a class that encapsulates all information needed to perform an action.

Question 20

What is the always-valid domain model guideline?

Answer 20

Says that domain model class should guard themselves from ever becoming invalid. This means validating input before instantiating objects.

Question 21

Why is it a bad idea to separate workers into modellers and programmers when working with a model-driven design?

Answer 21

If developers do not feel responsible for the model and do not realize how their refactoring changes the model, then the model could become weaker. Modellers loose understanding of the constraints on implementations their model results in.

Question 22

Why is it necessary to isolate the domain?

Answer 22

The part of the software that actually deals with problems from the domain is usually only a small portion. We need to decouple this central part of the system to avoid confusing the domain concepts with other concepts related only to software technology.

Question 23

What are some ways architectural frameworks can get in the way of development?

Answer 23

By making too many assumptions that constrain domain design choices or by making the implementation so heavyweight that development slows down.

A lot of the downsides of frameworks can be avoided by applying them selectively to solve difficult problems without looking for a one-size-fits-all solution. Elaborate frameworks can straitjacket application developers.

Question 24

What is the main criteria for an architecture in order to support domain-driven design?

Answer 24

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.

Question 25

What are the three patterns of model elements that express the model?

Answer 25

Entities, value objects and services.

Question 26

How do we distinguish between entities and value objects?

Answer 26

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.

Question 27

When should aspects of a model be a service?

Answer 27

There are aspects of the domain that are more clearly expressed as actions or operations, rather than as objects. These are best expressed as services.

A service is something that is done for a client on request.

Question 28

What is an entity?

Answer 28

An object that is defined primarily by its identity. They have life cycles that can change their form and content, but a thread of continuity must be maintained.

Question 29

What is the most basic responsibility of an entity?

Answer 29

To establish continuity so that behavior can be clear and predictable. Strip entities down to the most intrinsic characteristics, in particular those that identify it or are commonly used to find or match it. Add only behavior that is essential and attributes to support the behaviors

Look to remove behavior and attributes into other objects associated with the core entity.

Question 30

Why are all objects in the domain model not simply entities?

Answer 30

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.

Question 31

What are value objects?

Answer 31

An object that represents a descriptive aspect of the domain with no conceptual identity.

When we only care about the attributes of an element of the model, we classify it as a value object. Treat the value object as immutable. Do not give it an identity and avoid the design complexities necessary to maintain entities.

Colors are an example of value objects.

Question 32

How do we isolate the domain from external areas?

Answer 32

With a layered architecture. When domain-related code is mixed with the other layers, it becomes extremely difficult to see and think about.

Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application and infrastructure code.

A common architectural solution for domain-driven designs contain four conceptual layers:
- User interface
- Applicaiton layer: thin layer which coordinates the application activity. Does not contain bussiness logic or hold state of business objects. But it can hold state about an application task.
- Domain layer: Contains information about the domain
- Infrastructure layer: Supporting layer for all the other layers. It provides communication between layers and implements persistence for business objects.

Question 33

How do we express the domain model?

Answer 33

1. Services: Does not have an internal state, and its purpose is to provide functionality for the domain. A service usually becomes a point of connection for many objects. This is one of the reasons why service behavior should not be included into the domain objects.
2. Entities: Objects that have an identity which spans the life of a system and beyond.
3. Value objects: Objects that are used to describe certain aspects of a domain, and does not have an identity.

Question 34

What is the golden rule concerning value objects?

Answer 34

If value objects are shareable, they should be immutable. Value objects should be kept thin and simple.

Question 35

Why is a high degree of coupling between objects are sign of poor design?

Answer 35

Difficult to read, understand and change.

Question 36

Should we create services for each operation in the domain model?

Answer 36

No. A service should not replace the operation which normally belongs on domain objects. We should only create a service when an operations stands out as an important concept in the domain.

Question 37

What are the three characteristics of a service?

Answer 37

1. The operation performed by the service refers to a domain concept which does not naturally belong to an Entity or Value object.
2. The operation performed refers to other objects in the domain.
3. The operation is stateless.

Question 38

What are the two types of cohesion?

Answer 38

1. Communication cohesion: achieved when parts of the module operate on the same data.
2. Functional cohesion: achieved when all parts of the module work together to perform a well-defined task.

Question 39

What patterns do we use to manage the life cycle of a domain object?

Answer 39

Aggrefates: used to define object ownership and boundaries.
Factories and repositories: user to deal with object creation and storage.

Question 40

What are aggregates?

Answer 40

It is a behavioural boundary in the domain model. The central piece of an Aggregate is the Aggregate Root. It is the high-level API that provides access to the functionality within the Aggregate (other entities).

Question 41

What is a repository?

Answer 41

Class that encapsulate all the logic needed to obtain object references.