Domain Driven Design book

PART III C8 Breakthrough C9 making implicit concepts explicit

Digging out concepts Scrutinise awkwardness Contemplate contraditions

Model less obvious kinds of concepts Processes as domain objects

C10 supple design

Intention revealing interfaces Name classes and operations to describe their effect and

purpose, without reference to the means by which they do what they promise

names should conform to the UBIQUITOUS LANGUAGE so that team members can quickly infer their meaning

Consider using TDD approaches to promote thinking from the client view point

Side effect free functions Interactions of multiple rules or compositions of

calculations become extremely difficult to predict. function can be called multiple times and return the same

value each time Place as much of the logic of the program as possible into

functions, operations that return results with no observable side effects

Strictly segregate commands (methods that result in modifications to observable state) into very simple operations

Assertions side effects of operations are only defined implicitly by

their implementation, designs with a lot of delegation become a tangle of cause and effect

State post-conditions of operations and invariants of classes and AGGREGATES

Alternate to coded assertions is additional unit tests Conceptual contours

Decompose design elements (operations, interfaces, classes, and AGGREGATES) into cohesive units, taking into consideration your intuition of the important divisions in the domain

Align the model with the consistent aspects of the domain that make it a viable area of knowledge in the first place.

Standalone classes o object design. When you can, go all the way. Eliminate all

other concepts from the picture. Then the class will be completely self-contained

Every such self-contained class significantly eases the burden of understanding a MODULE.

Closure of operations closed operation provides a high-level interface without

introducing any dependency on other concepts. Declarative design

Generating a running program from a declaration of model properties is a kind of Holy Grail of MODEL-DRIVEN DESIGN, but it does have its pitfalls in practice.

declaration language not expressive enough to do everything needed, but a framework that makes it very difficult to extend the software beyond the automated portion

Code-generation techniques that cripple the iterative cycle by merging generated code into handwritten code in a way that makes regeneration very destructive

triage in order to get something delivered.Rule-based programming with an inference engine and a rule base is another promising approach to declarative design. Unfortunately, subtle issues can undermine this intention.

Angles of attack Carve off subdomains Drawn on established formalism

supple design reveals a deep underlying model that makes its potential clear

Over engineering often done in name of making things supple

Avoid unnecessary layers of abstraction C11 applying analysis patterns

Analysis patterns are knowledge to draw on C12 Relating design patterns to the model

Strategy aka policy Composite Why not flyweight?

PART IV C13 refactoring toward deeper insight

Initiation

Exploration teams Prior art Design for developers Timing Crisis as opportunity

C14 - maintaining Model Integrity Principles

Need agreed boundaries in the models for teams to work with - otherwise risk modifying each other’s code and assumed meanings differ

most fundamental requirement of a model is that it be internally consistent; that its terms always have the same meaning, and that it contain no contradictory rules

internal consistency of a model, such that each term is unambiguous and no rules contradict, is called unification

In an ideal world, we would have a single model spanning the whole domain of the enterprise

However ideal is not where we live In practical sense effort to achieve the ideal not

practical or cost effective Fair chance of experiencing subtle duplication and

contradictions Even at Enterprise scale model and code should

align Risk of over reach in model scope

Too many legacy replacements may be attempted at once

Large projects may bog down because the coordination over-head exceeds their abilities.

Applications with specialized requirements may have to use models that don’t fully satisfy their needs, forcing them to put behavior elsewhere

Conversely, attempting to satisfy everyone with a single model may lead to complex options that make the model difficult to use.

Bounded context Multiple models on big projects Ability to control definition limited by COTs solutions when code based on distinct models is combined, software

becomes buggy, unreliable, and difficult to understand 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 delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other CONTEXTS

do not worry about applicability outside those bounds Don’t mix idea of bounded context with modules

Different contexts will have different namespaces Modules organise within a context

Special care needs to be taken on the edge of bounded contexts with its neighbours

Symptoms of not having recognised model differences Obvious issues such as interfaces not matching up CI processes can help tease out / provide early

warning of some issues Early warning is confusion of lsngusge Combining distinct models can cause ...

Duplicate concepts False cognates Duplication of concepts lead to duplicated

implementation etc Continuous integration

When a number of people are working in the same BOUNDED CONTEXT, there is a strong tendency for the model to fragment

People can encounter serious problems. Yet breaking down the system into ever-smaller CONTEXTS eventually loses a valuable level of integration and coherency

Contributes to the model as much as the Implementation & model integrity can be protected with ...

Step by step reproducible merge/build technique Automated testing Rules on how long changes can exist before

integrating in Creates a biproduct of constant exercise of

ubiquitous language Context map

Risk of different teams not knowing the context boundaries resulting in blurring of the model

Code reuse between BOUNDED CONTEXTS is a hazard to be avoided

You can reduce confusion by defining the relationship between the different contexts and creating a global view of all the model contexts on the project.

Use clear ubiquitous language to name each bounded context

Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing

Use routing to cross contexts Relationships between bounded contexts

patterns cover a range of strategies for relating two models that can be composed to encompass an entire enterprise

If context relationships are ambiguous then use a context map to draw out clarity

Shared kernel

Uncoordinated teams working on closely related applications can go racing forward for a while, but what they produce may not fit together. They can end up spending more on translation layers and retrofitting than they would have on CONTINUOUS INTEGRATION in the first place

Resolve by... Designate some subset of the domain model

that the two teams agree to share Sharing can include code, dB etc No change without consultation CI is key

Typically embodies Core domain Generic subdomain

Reduce duplication not eliminate - complete elimination could create blurred boundaries

Customer/supplier dev teams 1 system can feed a downstream solution If downstream has change veto on upstream things

can be become very constraining

Process for coordinating change request if cumbersome can also choke progress

Need formalise relationships to accommodate pressures, but needs to be practical & workable

Eg change controlled in iterations Stakeholders input in sprint planning Up and downstream teams are considered

stakeholders as much as business Use CI to help validate boundary

relationships Customer / supplier = up & down stream

Conformist When all teams driven by same ‘source’ then

customer/supplier won’t work - motivation is lost When locked should consider ...

Remove dependency on upstream Assume upstream will not support

requirements Not over estimate cost of dependency Establish own models to encapsulate

upstream Introducing an anti corruption layer

Conforming to upstream models will keep things simple

Anti corruption layer Avoid other systems on the boundaries impacting

the internal model ERP and other legacy systems Scenarios with complex interfaces risk

impacting If risk of impact the internal model then integration

layer should be more defensive Create an isolating layer to provide clients with

functionality in terms of their own domain model The layer talks to the other system through its

existing interface, requiring little or no modification to the other system

Internally, the layer translates in both directions as necessary between the two models

discussion of a mechanism to link two systems might bring to mind issues of transporting the data from one program to another or from one server to anothe

Anti corruption layer design ... public interface of the ANTICORRUPTION

LAYER usually appears as a set of SERVICES, although occasionally it can take the form of an ENTITY

Building a whole new layer responsible for the translation between the semantics of the two systems gives us an opportunity to reabstract the other system’s behavior and offer its services and information to our system consistently with our model

combination of FACADES, ADAPTERS (both from Gamma et al. 1995), and translators, along with the communication and transport mechanisms usually needed to talk between systems

Remember, an ANTICORRUPTION LAYER is a means of linking two BOUNDED CONTEXTS

Separate ways Sometimes the effort of integration outweighs

benefits Declare a BOUNDED CONTEXT to have no

connection to the others at all, allowing developers to find simple, specialized solutions within this small scope

Open host service Typically for each BOUNDED CONTEXT, you will

define a translation layer for each component outside the CONTEXT with which you have to integrate

When a subsystem has to be integrated with many others, customizing a translator for each can bog down the team

Recommend... Define a protocol that gives access to your

subsystem as a set of SERVICES Open the protocol so that all who need to

integrate with you can use it expand the protocol to handle new

integration requirements use a one-off translator to augment the

protocol for that special case Published language

translation between the models of two BOUNDED CONTEXTS requires a common language.

If existing bounded contexts are complex, difficult then translating between them may not make sense, therefore have a simpler published language

Use a well-documented shared language that can express the necessary domain information as a common medium of communication, translating as necessary into and out of that language

Choosing you model context strategy Team decisions or higher

Teams needs to define the bounded contexts and the relationships between contexts

Entire team needs to understand boundaries and relationships

Accept politics of teams and organisations can impact particularly integrating contexts

Transforming boundaries Accept can’t change boundaries of external systems

Easy to assume each system is a bounded context - may not be true

May have opportunity to influence or shape Relationships with external systems - pattern options

Separate ways Anti corruption layer Conformist

Catering for special needs with distinct models Deployment

Bounded contexts can impact deployment from deployment sequencing and beyond

Deployment plans should be feed into bounded context

When a project is underway Often not starting with a clean sheet but things

underway Need to reflect team realities

Transformations Merging contexts: separate ways —> shared kernel

Ensure both are internally consistent before trying to combine

Address process/code changes e.g.. How Code is shared Naming conventions Combined build processes as CI Start with a simple subdomain

Form a group of two to four developers, drawn from both teams, to work out a shared model for the subdomain

Team members, drawn from both teams, to work out a shared model for the subdomain. Regardless of how the model is derived, it must be ironed out in detail

Remove translations Merging Contexts: Shared Kernel —> Continuous

Integration Bringing bounded contexts together impacts teams

& language, design etc processes needed for CONTINUOUS

INTEGRATION (shared code ownership, frequent integration, and so on) are in place on each team, separately

Harmonise processes so everyone works the same way

Start circulating people across the teams Clarify the individual models independently Once settled start the merging of the common

kernel Phrasing out a legacy system

Legacy systems can be difficult to phase out as they become so ingrained into business processes

Help phase out by ... Identifying outstanding functionality and

deliver Identify what goes into the anti corruption

layer Implement and deploy Watch for anti corruption layer elements that

can also decommission as phase out completed

Unpack and eliminate any unneeded elements

Open host service —> published language If industry language is available evaluate and use if

possible If a predefined language unavailable then sharpen

core to serve this purpose Remember any existing language needs to be stable

in its meaning and definition Adopt standard patterns for the exchange e.g use of

XML Build what ever necessary translation layers

Bounded contexts are not irrevocable

C15 Domain Distillation Distilling the domain model helps by ...

Aids all team members in grasping the overall design of the system and how it fits together

Facilitates communication by identifying a core model of manageable size to enter the UBIQUITOUS LANGUAGE

Guides refactoring Focuses on the most valuable parts of the model Facilitates communication by identifying a core model of

manageable size to enter the UBIQUITOUS LANGUAGE Apply top talent to the CORE DOMAIN, and recruit

accordingly. Spend the effort in the CORE to find a deep model and develop a supple design—sufficient to fulfill the vision of the system. Justify investment in any other part by how it supports the distilled CORE.

Who does the work? domain. This limits their usefulness and reinforces the

tendency to assign them to supporting components, sustaining a vicious circle in which lack of knowledge keeps them away from the work that would build domain knowledge.

essential to break this cycle by assembling a team matching up a set of strong developers who have a long-term commitment and an interest in becoming repositories of domain knowledge with one or more domain experts who know the business deeply

usually not practical to hire short-term, outside design expertise for the nuts and bolts of creating the CORE DOMAIN, because the team needs to accumulate domain knowledge, and a temporary member is a leak in the bucket

Domain-Specific Application Frameworks (Fayad and Johnson 2000) gives an overview of the state of this art Of off the shelf domain models

greatest value of custom software comes from the total control of the CORE DOMAIN

Approaches to distillation DOMAIN VISION STATEMENT communicates the basic

concepts and their value with a minimum investment Write a short description (about one page) of the

CORE DOMAIN and the value it will bring, the “value proposition.” Ignore those aspects that do not distinguish this domain model from others. Show

how the domain model serves and balances diverse interests. Keep it narrow. Write this statement early and revise it as you gain new insight.

HIGHLIGHTED CORE can improve communication and help guide decision making—and still requires little or no modification to the design.

Distillation doc distillation document outlines the essentials

of the CORE DOMAIN Flagged core

Take the model eg off the shelf and annotate key elements

Distillation Document as Process Tool COHESIVE MECHANISMS can be encapsulated with

versatile, communicative, and supple design Partition a conceptually COHESIVE MECHANISM into

a separate lightweight framework. Particularly watch for formalisms or well-documented categories of algorithms

Expose the capabilities of the framework with an INTENTION-REVEALING INTERFACE.

Now the other elements of the domain can focus on expressing the problem (“what”), delegating the intricacies of the solution (“how”) to the framework.

SEGREGATED CORE makes the CORE directly visible, even in the code, and facilitates future work on the CORE model

Refactor the model to separate the CORE concepts from supporting players (including ill-defined ones) and strengthen the cohesion of the CORE while reducing its coupling to other code

Factor all generic or supporting elements into other objects and place them into other packages, even if this means refactoring the model in ways that separate highly coupled element

GENERIC SUBDOMAINS provide a contrast to the CORE DOMAIN that clarifies the meaning

Identify cohesive subdomains that are not the motivation for your project. Factor out generic models of these subdomains and place them in separate MODULES. Leave no trace of your specialties in them

You can consider implementing this space by Off the shelf solutions

+ve Less code to develop. +ve Maintenance burden externalized. +ve Code is probably more mature,

used in multiple places, and therefore more bulletproof and complete than homegrown code.

-ve depend upon supplier providing good quality code

-ve maybe over kill for requirement -ve integrating foreign elements can

be difficult -ve added additional dependencies

Use a published design or model +ve More mature than a homegrown

model and reflects many people’s insights

+ve Instant, high-quality documentation

-ve May not quite fit your needs or may be overengineered for your needs

Out source implementation +ve Keeps core team free to work on

the CORE DOMAIN, where most knowledge is needed and accumulated.

+ve Allows more development to be done without permanently enlarging the team, but without dissipating knowledge of the CORE DOMAIN.

+ve interface-oriented design, and helps keep the subdomain generic, because the specification is being passed outside.

-ve requires time from the core team, because the interface, coding standards, and any other important aspects need to be communicated.

-ve significant overhead of transferring ownership back inside, because code has to be understood. (Still, overhead is less than for specialized subdomains, because a generic model presumably requires no special background to understand.)

In-house implementation +ve Easy integration. +ve You get just what you want and

nothing extra +ve Temporary contractors can be

assigned. -ve Ongoing maintenance and training

burden. -ve o underestimate the time and cost

of developing such packages Generic doesn’t mean usable

Project risk management

C16 Large Scale Structure

Evolving order System metaphor

The ‘naive metaphor’ and why we don’t need it Responsibility layers Choosing appropriate layers Knowledge level Pluggable component framework How restrictive should a structure be? Refactoring toward a fitting structure

Minimalism Comms & self discapline Rectructuring to get supple design Distillation lightens the load

C17 Bringing the strategy together

Combining large scale structures & distillation Assessment first Who sets the strategy

Emergent structure & app dev Customer focussed architecture team

Essential strategic design decision making Decision process must absorb feedback Plan allows for evolution Architecture teams must not siphon off all best & brightest Strategic design requires minimalism and humility

Objects are specialists, developers are generalists Same rules for teach frameworks

Don’t build frameworks for dummies Be aware of the master plan

PART II Building blocks of model driven design

Principles informing model driven design responsibility-driven design,” put forward in Wirfs-Brock et

al. 1990 and updated in Wirfs-Brock 2003 design by contract” described in Meyer 1988 nd of other widely held best practices of object-oriented

design, which are described in such books as Larman 1998

Isolating the domain (C4) Layered Architecture

User interface / presentation layer Application layer Domain or model layer

This layer is the heart of business software Infrastructure layer Risk that the domain model is diluted in the code by UI

elements, SQL elements embodying bits of the model When the domain-related code is diffused through

such a large amount of other code, it becomes extremely difficult to see and to reason about

Changes can easily start to impact the model Model driven advises...

Partition a complex program into layers Develop a design within each layer that is cohesive

and that depends only on the layers below Follow standard architectural patterns to provide

loose coupling Concentrate all the code related to the domain model

in one layer and isolate it from the user interface, application, and infrastructure code.

domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks etc

software that specifically solves problems from the domain usually constitutes only a small portion of the entire software systemProgress: 100%

Decouple domain objects from the other system elements

Helps confusing the domain from the technology issues Like separating constellations from the general night sky Use techniques developed to help achieve the separation

Use of frameworks such as J2EE are fine but only use what benefits the solutionProgress: 100%

Do not let framework dictate Use only what is needed eg do you need model as entity

beans? Be careful of being straight jacketed by elaborate

frameworks Trying approach for 1st time on small projects which typically

have limited time frames - hi risk of error Challenging learning curve No experience on what compromises are safe Smart UI ‘anti-pattern’

Progress: 100% Benefits of approach

Immediately high productivity for simple solutions

Less capable developers can bring value quickly as requires little training

Applications are decoupled Requirements can be clarified through

releasing prototypes to users Database works well for data level

integration Works well with 4GLs Maintenance teams can quickly rework parts

of a solution if they can’t figure it out because of localisation

Disadvantages Integration outside the dB is difficult No abstraction of business problem No reuse opportunities Complexity can slow things very quickly

Use a 4Gl not general languages like Java Once started can’t change design approach Idle ground option - Fowler (2002) describes the

TRANSACTION SCRIPT, which separates UI from application but does not provide for an object model

This pattern won’t work with model driven design Model expressed in software (C5)

Entities (aka reference objects) Will have lifecycles Need to be defined so they can be uniquely trackedo Key points

When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model

Keep the class definition simple and focused on life cycle continuity and identity.

Define a means of distinguishing each object regardless of its form or history

Be alert to requirements that call for matching objects by attributes.

Be alert to requirements that call for matching objects by attributes.

The model must define what it means to be the same thing.

Value objects Keypoints

These are the objects that describe things. Tracking the identity of ENTITIES is essential, but

attaching identity to other objects can hurt system performance

When you care only about the attributes of an element of the model, classify it as a VALUE OBJECT

An object that represents a descriptive aspect of the domain with no conceptual identity is called a VALUE OBJECT

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

Colors are an example of VALUE OBJECTS that are provided in the base libraries of many modern development systems

Copy vs share Copying objects can result in resource consumption

but better than the performance impacts Only share objects when...

Saving storage space or storage related constraints

Comms overhead is low e.g using centralised SCR with hi performance networks

When the shared object must be strictly immutable

Special cases for mutability... Value changes frequently Object creation or deletion is expensive If replacement rather than modification will

disturb clustering Services

Good characteristics Operation relates to a domain concept not a natural

part of an entity or value object Interface is defined in terms of other elements of the

domain model

Operations are stateless Services and the isolated domain layer

Partitioning Services into layers Application

Digests input Sends message to domain service for

fulfillment Listen for confirmation Decides to send notification using

infrastructure service Domain

Interacts with necessary objects Supplies confirmation of result

Infrastructure Granularity Access to services Medium-grained, stateless SERVICES can be easier to reuse

in large systems because they encapsulate significant functionality behind a simple interface.

Fine grained Services can introduce significant overhead in comms in a distributed system

fine-grained domain objects can contribute to knowledge leaks from the domain into the application layer

judicious introduction of domain services can help maintain the bright line between layers

Elaborate architectures should be used only when there is a real need to distribute the system or otherwise draw on the framework’s capabilities

Modules aka packages Agile modules

Modules can co-evolve Should refactor along with the model

It can be tempting to allow refactoring lead to model drift

Pitfalls of infrastructure driven packaging Avoid tech platform driving module structure But infra influences can be helpful e.g enforcing layer

isolation Costs of elaborate platform structures can be ...

partitioning conventions pull apart the elements implementing the conceptual objects, the code no longer reveals the model

only so much partitioning a mind can stitch back together, and if the framework uses it all up, the domain developers lose their ability to chunk the model into meaningful pieces

Obscures the domain object relationships Recommends...

Choose MODULES that tell the story of the system and contain a cohesive set of concepts

This often yields low coupling between MODULES, but if it doesn’t, look for a way to change the model to disentangle the concepts, or search for an overlooked concept that might be the basis of a MODULE that would bring the elements together in a meaningful way.

Give the MODULES names that become part of the UBIQUITOUS LANGUAGE. MODULES and their names should reflect insight into the domain.

Unless there is a real intention to distribute code on different servers, keep all the code that implements a single conceptual object in the same MODULE, if not the same object.

Use packaging to separate the domain layer from other code

Associations For every traversable association in the model, there is a

mechanism in the software with the same properties. It is possible to make associations clearer by ...

Imposing a traversal direction Adding a qualifier, effectively reducing multiplicity

Often comes with deeper understanding Consistently constraining associations in

ways that reflect the bias of the domain not only makes those associations more communicative and simpler to implement,

Eliminating nonessential associations Constrain relationships as much as possible

Bidirectional relation means both objects can only understood together

Deep understand can result in relationships being defined with qualifications

Modelling paradigms Object approach often used as it provides a balance of

simplicity and complexity Simplicity in implementation Ability to capture and embody domain ideas Avoids being dragged into R&D needs Well established and supported

Esoteric modelling approaches will result in not enough devs mastering it and using the approach properly

Non objects in an object world If small parts are awkward in the paradigm - ok to

live with If large parts are awkward then reconsider approach Mix paradigms if necessary eg rules engines don’t fit

an object paradigm

Rules of thumb for mixing paradigms... Don’t fight the implementation paradigm Lean on the ubiquitous language Don’t get hung up on UML Be skeptical. Is the tool really pulling its weight?

relational paradigm is a special case of paradigm mixing. The most common nonobject technology, the relational database is also more intimately related to the object model than other components, because it acts as the persistent store of the data that makes up the objects themselves

C6 - Life cycle of a domain object Aggregates Factories

Choosing factories & their sites When all you need is a constructor Designing the interface Where does invariant logic go? Entity factories v value object factories Reconstituting stored objects

Repositories Querying a repo Implementing a repo Working within your frameworks Relationship to factories

Designing objects for relational dbs C7 a worked example

PART I Putting domain model to work (C0)

Progress: 100% Utility of a model in domain driven design

Model and the heart of the design shape each other Model is the backbone of a language used by all team

members Model is distilled knowledge

Collectively agreed Common language

Utility Crunching knowledge (C1)

Ingredients of Effective Modeling Binding the model and the implementation Cultivating a language based on the model Developing a knowledge-rich model Distilling the model Brainstorming and experimenting

Knowledge crunching Can be a team process Collaborative with domain experts Different models maybe tried and rejected to derive

essence of the underlying model

Waterfall model of business analysts talk to SMEs fails because of not having feedback

Developer insight is not tested with SMEs Iterative approach can fail because it doesn’t drill in deep

enough to get sufficient depth of knowledge to establish the abstractions

Team dynamics can change as model is ‘crunched’ as process of building domain knowledge is driven

“ Knowledge crunching is an exploration, and you can’t know where you will end up”

Continuous learning All teams leak knowledge - people leave etc Highly productive teams grow their knowledge consciously

both in subject domain and technically Self educated team members make a good core that are best

suited to taking critical areas Knowledge rich design Deep models

Communication and use of language (C2) Modeling out loud

Communicating the domain model in the spoken word will tease out the appropriate phraseology

Consider Pinker’s Language Instinct Use of models to convey the ideas

One team, one language Don’t have separate languages for Dev and stakeholders Don’t use different language because technical ones are too

abstract etc If things too abstract, then how do you know the

abstraction is correct?

Ubiquitous language Consistency of language needed across all channels of

comms not just docs and UML models Translation blunts communication and makes knowledge

crunching anemic. Documents and diagrams

Simple aka informal UML Can be very powerful. Particularly object models

Careful about modelling out every aspect you can still end not representing key issues such as object behaviour & interactions

The ability for the diagram to communicate the ideas is more important that slavish following of modelling notation rules

The diagram is not the model - the diagram is an aide to communicating the model

Explanatory models used to help communicate ideas without out restrictions of model notation

Written design documents Whilst written docs are inevitable part of any delivery they

need to be instep with the code Using code as the means to communicate the solution

means it is crucial that it is clear But code as only documentation can be as challenging as a

full blown model - too much detail making it hard to see the principles and key ideas

Don’t use docs to duplicate what code does best - provide explicit detail. Use docs to illuminate meaning

Code can and ideally should be the bedrock of documentation It needs to be cared for - names of methods, variables etc

can no longer reflect true purpose Code can be obscure or obtuse Keeping things clean and clear needs discipline Code must use the same language as the requirements

Binding model and implementation (C3) Model paradigms and tool Support Hands-on modelers

Separating Dev from the modelling means you are trusting the model communicate everything - likely to miss details/nuances

Risk of breaking feedback loop separating modellers and devs - result issues in model don’t get resolved

Ivory tower perceptions can creep in Model issues not engaged with then it can get jettisoned

during Development Risk of skills transfer not happening as developers don’t

gain domain insight and vice versa Any technical person contributing to the model must spend

some time touching the code, whatever primary role he or she plays on the project.

the knowledge and skills of experienced designers won’t be transferred to other developers if the division of labor prevents the kind of collaboration that conveys the subtleties of coding a MODEL-DRIVEN DESIGN

Traditional separate analysis and design models can fail ... Deeper understanding established during Development will

change models Pure analysis models become impractical for a foundation

of development as they don’t consider design issues

As analysis model will no longer reflect implementation its value is limited

By not separating analysis don’t use this as a reason for go depth of analysis

Model driven design ... MODEL-DRIVEN DESIGN discards the dichotomy of analysis

model and design to search out a single model that serves both purposes. Setting aside purely technical issues, each object in the design plays a conceptual role described in the model. This requires us to be more demanding of the chosen model, since it must fulfill two quite different objectives.

MODEL-DRIVEN DESIGN has limited applicability using languages such as C, because there is no modeling paradigm that corresponds to a purely procedural language. Those languages are procedural in the sense that the programmer tells the computer a series of steps to follow.

Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious. Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain. Demand a single model that serves both purposes well, in addition to supporting a robust UBIQUITOUS LANGUAGE.

Every developer must be involved in some level of discussion about the model and have contact with domain experts

Superimposed models on each other cause confusion at best

should only have 1 model in a context