UNITV
UNITV
• Implicit concepts are concepts that exist but , for some reason, the
domain experts don’t talk about them explicitly. It takes some
time until the developers actually realize the existence of those
implicit concepts, by means of hints while discussing the model or
at later stages, when several other concepts are already set in
place.
Digging out concepts
• refactor the code to reflect the new model and find a cleaner design.
Scrutinize awkwardness
• Different domain experts can have different views on a particular part of the
• Most of the times, the contradictions are merely terminology differences and
domain experts.
Read the book
• Supple design is the complement to deep modeling. Once you've dug out implicit
concepts and made them explicit, you have the raw material. Through the
iterative cycle, you hammer that material into a useful shape, cultivating a model
that simply and clearly captures the key concerns, and shaping a design that
allows a client developer to really put that model to work. Development of the
• Intention-Revealing Interfaces
• Assertions
• Standalone Classes
• Closure of Operations
•
• Intention-Revealing Interfaces
• The interface of a class should reveal how that class is to be used If developers don’t
understand the interface (and have access to source), they will look at the
lost
• So, name classes and methods to describe their effect and purpose, without reference
to their implementation
• Write a test case before the methods are implemented to force your thinking into how
Side-Effect-Free Functions
and queries
• Commands are operations that affect the state of the system. Side effects are
changes to the state of the system that are not obvious from the name of the
operation. They can occur when a command calls other commands which call
other commands etc.; the developer invoked one command, but ends up
After you have performed work on creating as many side-effect free functions and value
objects as possible, you are still going to have command operations on Entity objects.
• Modules and Aggregates are two techniques already discussed for doing
this; They don’t eliminate dependencies but tend to reduce and/ or limit
number;
• When it fits, define operations such that their return type is the same
When working in a large system, with a large model where we have several teams working on
it, a section of the model will likely end up being interpreted, and adjusted in code, in
These different interpretations and code adjustments will end up corrupting the model,
The best way to deal with this issue is to break the large model into smaller independent
models. Breaking down a model is done by identifying bounded contexts and using context
It’s common, and natural, for projects to have several different models within them.
However, the boundaries in which the different models connect are fragile and prone to
Explicitly define the context within which a model applies. Explicitly set boundaries in
terms of team organization, usage within specific parts of the application, and physical
manifestations such as code bases and database schemas. Keep the model strictly
consistent within these bounds, but don’t be distracted or confused by issues outside.
Bounded context
concepts and rules. The different models, used in different contexts can and
will overlap. They might relate to the same data, but represent it in a
context the User entity might be just a fraction of the whole User data.
Bounded context
Duplicate concepts: The same concept is represented and implemented in more than one way.
This means that when a concept changes, it has to be updated in several places, and the
developers need to be aware of the several different ways of doing one same thing, as well as
False cognates: When two people are using the same term and they think they are talking
about the same thing, but they are actually thinking of different things.
Bounded context
Context map:
When the bounded context boundaries are not explicitly clear, those boundaries tend to get blurred by
promiscuously mixing code that exists in different bounded contexts. This leads to code that is tightly
coupled and difficult to change in isolation.To make the bounded contexts ecosystems explicitly clear,
Create a global view of all bounded contexts and their relations, using context maps, naming them and
adding them to the ubiquitous language. Identify the points of contact between bounded contexts,
together with the used translations and abstractions. All developers must know the boundaries and to
several ways of how you can integrate between multiple bounded contexts:
Partnership
Shared kernel
Customer supplier
Conformist
Anticorruption Layer
Partnership
It describes more about the relationship between teams as oppose to actual code. This typically
happens when 2 teams working on 2 bounded contexts have aligned and dependent set of goals.
Each team should at least understand some of their partner’s Ubiquitous Language, namely the
things that are interesting to their own context. This can work fairly well when both bounded
contexts are at early stages of the project, where communication is quick and more efficient than
implementing some of the other techniques. When both sides become more established, teams
may incur too much commitment in understanding each other’s Ubiquitous Language. Of course,
if a team was to work on both such bounded contexts, the ‘Partnership’ relationship would be
relationship between bounded contexts
Shared Kernel
all relevent teams. In code terms, you may have a shared library, or
Customer Supplier
downstream, where the upstream is the supplier, and has to try and
decision of what the customer gets comes from the supplier. This
Conformist
downstream bounded context implements a layer between itself and the upstream. This
layer is responsible for translating the objects given by the upstream into its own
models. This approach will guarantee the integrity of the downstream bounded context
and keeps it completely ignorant of any foreign concepts. This approach is generally
useful for integrating new features to some existing legacy software, where you can treat
the existing legacy software as a black box bounded context and create an ACL for the
relationship between bounded contexts
I will talk about these two approaches together as they both define a relationship where
the upstream provides a set of well documented or readily available information about
the integration models. This is built on top of the Conformist approach from earlier,
where the downstream is a lot more tolerable. The upstream will also need to provide
version support. Typically the upstream bounded context will support multiple clients
and have no interest in especially supporting particular one. For example, to conform to
Amazon APIs, the downstream will have confidence in the integration by understanding
Strategic Domain Driven Design with Context
Mapping
Many approaches to object oriented modeling tend not to scale well when the
technique, part of the Domain Driven Design (DDD) toolkit, helps the architects and
developers manage the many types of complexity they face in software development
projects. Different from other well known DDD patterns, context mapping applies
to any kind of software development scenario and provides a high level view that
might help the developers to take strategic decisions, like whether to go for a full
technique, part of the Domain Driven Design (DDD) toolkit, helps the architects and
developers manage the many types of complexity they face in software development
projects. Different from other well known DDD patterns, context mapping applies
to any kind of software development scenario and provides a high level view that
might help the developers to take strategic decisions, like whether to go for a full
Partnership
Shared kernel
Customer supplier
Conformist
Anticorruption Layer
domain is the thing why software exists and is about. Evans divides the domain into three subdomains.
Core Domain: The core domain represents a competitive advantage and the software’s reason for being. It is a hearth of the
software with the most fundamental business rules, use cases, and domain models. It usually is the smallest part of the
codebase. In other words, it is the most critical 20% part of the software.
Supporting Domain: Supporting domains are supporting subsystems of software. The core can still exist without them but
does not makes it alone to its users. There can be multiple supporting domains in one system. For example, the supporting
domain is for the core domain, the same thing as invoicing for Amazon.
Generic Domain: A generic domain is the least custom part and the least important part of the software. It is not specific to
your domain, and it is widespread in other systems. I am currently working on an employee’s timesheets information system,
and the generic domain for this software is an external time tracker for each of the employees.
Core Domain
Core Domain: The core domain represents a competitive advantage and the software’s reason
for being. It is a hearth of the software with the most fundamental business rules, use cases,
and domain models. It usually is the smallest part of the codebase. In other words, it is the
Generic Domain: A generic domain is the least custom part and the least important part of the
currently working on an employee’s timesheets information system, and the generic domain
for this software is an external time tracker for each of the employees.