extremely encouraging to see hundreds of people interested in domain driven
design along with how to use domain-driven design in with dot net so
welcome thank you for attending and taking your valuable time to look into
this just to you know set the stage i'm the author of the book implementing
domain-driven design which is based on the original seminal work of air Kevin's
and i'm also the instructor of the idd workshop which you can find that I DD
workshop com
it's a three-day class which is based quite a bit on the subject matter of the
book and covers in the first day
strategic design and architecture the second day is devoted to tactical design
and then on day three we switch back to strategic design with integration and
look at the rest of the application so if you're interested in taking a really
deep dive into this
I teach both public and company private workshop so you're welcome to visit ID
workshop , contact me for further information and i was hoping to get a
couple hundred more followers on Twitter today this is how you're going to find
out most of the breaking news of things that i'm working on and I do blog and
i'll be blogging further on this topic of using DVD with dotnet and and the
later session at five this evening on aggregates and entities with entity
framework and as your storage tables so if you want to take note of my blog or
my Twitter account you'll
find out when those are available so today at this point what we're going to
talk about is sort of the high level
I hate to disappoint you but you won't learn any secrets about optimizing your
experience with visual studio in this session
what we're really going to do is look at why enterprise applications as a whole
or enterprise subsystems typically could benefit from having a domain driven
design mindset using DD on your project and then what we're going to do is
experienced the mental model
what is a mental model well this is actually the way your business people
want to think about domain driven or about their applications about the
software and how domain-driven design can be a guide to exploring and learning
about what your experts think and how their thought process can be improved
and the tools the two major tools that we use for this in strategic design is
the bounded context and ubiquitous language and then we'll look at
strategic design and some more detail
sort of a broader view point of review of strategic design within DD and then
we'll also introduce you to some of the tactical modeling patterns of domain
driven design primarily aggregate and aggregate is the 5 p.m. session that
will take you into actually how to implement aggregates with entity
framework and with event sourcing and sewer storage cables
ok so that's an overview of where we're going
so you start out on a project
you talked with some of your team members you read some requirements and
what your modeling is a scrum based application management tool which means
that you're going to use the language of scrum
hopefully you'll name your aggregates or your entities about with names from
scrum like product product is the thing that you are developing as someone
working on a software project and within a product you have backlog items and
those backlog items as you know many of you are aware contain the stories and
tasks necessary to complete a portion of the product and a portion of the product
is controlled under a sprint
that's where the activity of actually developing the software occurs and then
you have a release so backlog item release and sprint are all considered
part of your product and then under backlog items you have tasks and tasks
have estimation log entries so as you work on each task on a daily basis or
weekly basis you're able to basically estimate how many hours you have
remaining and any other helpful information about the estimation of the
task notice though that releases have scheduled backlog items and Sprint's
have committed backlog items ok so that's sort of like a basic model
there's actually more to a scrum model but if you think about it this is kind
of where you would conceptualize the the main parts of a scrum
application management tool but then the team starts thinking about the problem
that they're working on and they say oh yeah and we need users and this is going
to be a SAS you know a software-as-a-service application so we
need tenants and within tenants we have users and users have permissions and so
you add these concepts to the model of course
it seems natural that these belong there
after all what will you do without users and then management gets involved you
know the sea level management says you know we want to do we want to actually
integrate forum discussions and calendars into our model because we want
developers and product owners to be able to have tons about the product
the backlog items the releases the sprints that they're working on even
individual tasks so let's add in forums discussions and posts and we also want
to have to be able to plan milestones in our projects we want to plan for sprint
meetings we want to plan for retrospective meetings there
there's a lot of a sort of date based things or calendar events that we want
in our model so let's build calendars and two along with our forums
oh yeah and don't forget account management how are we going to make
money after all
well we need to have payment information and actually this is this is going to be
a lot more complex than just account and payment but let's hold it right there
for now let's just kind of leave those
as a representative view point of how we're going to deal with gathering
income for putting subscribers in touch with our software
oh and and yeah don't forget also that we need to support these folks that are
going to be using our software as a service platform and so we need to have
support plans with incidents
yeah that's that's actually non-trivial - huh I wonder if we could purchase
something for accounts and support plans will have to look into that but for now
let's just leave these placeholders there
oh yeah and we have users now but the users within the team are they within a
team
yeah it's a team and each team has a product owner and they have team members
in fact there are even volunteers on the so wouldn't it be a good idea to include
teams product owners team members
oh yeah and then there's resource management how do we know that a product
owner or a volunteer team member is available to work on a specific backlog
item task that they volunteered to work on
if we try to set their time up for working on these various you know pieces
of this project or a project how will we know that they actually have time to do
that so let's add in time management and we're going to model a time-consuming
resource with the schedule and availability and you know for every
single one of these objects that are represented in our model here there
could actually be you know half a dozen maybe even a dozen supporting concepts
behind at least some of them do you see how this is kind of growing
in to a point where
what is the model actually what are you modeling what is the core is it time
management is that really what your software as a service company wants to
is it forums and calendar events is it support while all these are necessary
things maybe even commodities that you need to leverage but what is the core
where do we take this project from here
how do we deal with the complexity of each of these add-on concepts without
losing control
you know I don't know about you but i I've worked on enough projects to be
frightened by the outcome of of this
I mean this is just a conceptual kind of model that occurred over maybe 30
minutes of of thinking actually but you know after you spend months of software
development do you know what this model is going to look like it might look like
a model that I got to to view at one point there was a conference table in a
conference room that started about over here and three or four architects took a
UML diagram and rolled it out cross the conference table
you know and it may have stopped somewhere about here and then each of
these architects lined up at different sections of the UML diagram and they
would talk to a portion of the UML diagram that they were familiar with and
why this thing with an arrow from there . and clear over here was related to
this other thing
now do you really have to be that smart have that good of a memory in order to
develop enterprise software
I hope not
because I found that I personally found that very confusing and you know it
wasn't five minutes after i got clarity or what i felt i had clarity on this
portion of you know 12 objects for classes on a UML diagram and then we
focused over here that i had to say now wait a minute but why was why was that
here again oh so what you're saying is that this chair is a portion of the
concept that's over here
yes ok so when we face this kind of software development
actually you know probably the dummy and all of us should just cry out and say
there has got to be an easier way and that is what dd speaks to is the easier
way
now i'm not going to try to tell you that DVD is easy because if you were to
try to control the complexity of this model that you're looking here at here
or even the one in that UML diagram that i was talking about
it's going to take you know real mental effort but the point is that you have
the tools that are necessary to help you divide and conquer
and let's just say that it's no coincidence that i introduced each of
the aspects of this growing morphing model piece by piece because perhaps you
can even now kind of grasp where we're headed with DD strategic design and how
we're going to use the strategic design tools to try to find control of of this
and well let me not say this model but these models before these models become
this model one model and everything is completely out of control
so yeah we want to avoid
this kind of you know caveat warning here there be dragons
you know all those warnings don't get into this situation in a domain model
it's unnecessary and you may even in doing this lose sight of what the really
important things are the things that I your organization should really be
focusing on and you might be losing out on opportunities to reuse where reuse
makes a lot of sense if it is not to your company's competitive or business
advantage to focus on any one of these areas so in my eye dee dee workshop i
like to say that in introducing didi to you
this is probably the most important thing that you will walk away with today
so you know like if if you trip on the escalator going down stairs and hit your
head and you forget where you live
don't worry microsoft will help you find your home but don't forget this because
this is this is the cornerstone of domain driven design bounded context
where you model is ubiquitous language right so what we're interested in is
actually constraining not in allowing a model to grow and grow and grow and grow
but actually what we want to do is purposely constrain the domain model so
that inside a bounded context we are modeling a single ubiquitous language
which means that the language is driving what belongs inside and driving
everything else out
now many of you are are immediately saying yeah
Oh bounded context what is that
how do i how do I sort of squeeze bounded contact text into what I know
what I use every day and i'm just going to give you a little hint here because I
think you need this many of you are just saying here's another term that I'm
going to have to go read 90 pages or 300 pages about before i'm going to
understand that may maybe I still won't really know what it is
ok think of a bounded context as everything that you need for an
application or subsystem
so if you depending on how you view your development environment
you're using visual studio probably are think of creating a solution a visual
studio solution for a bounded context and within that solution
you might have a different project for your domain model you might have a
different project for you I your web interface you might have a different
project for your services layer things like that but if you thought about the
solution as being the bounded context that will help you at least follow the
rest of the this discussion now there's also a caveat in that because I hesitate
to tell you that a bounded context is a solution or could be like a solution
because it would be really easy to just keep creating project after project
after project after project within that solution and I've just hinted or
expressly stated don't do that
so think of a bounded context not only as the mob
I and the services that are supporting what you're doing but you also have to
think of the bounded context
of where other things don't be long all right
and that's where we're going to discuss this is what doesn't belong in the model
that we just reviewing and if it doesn't belong in that model has been that
bounded context where does it belong
now let me give you another hint about this visual studio solution if we are
modeling an agile project management tool then this bounded context and that
visual studio solution will be called the agile project management context or
agile project management . you know whatever that is solution that by giving
that visual studio solution a name
it's immediately tell you there are things that don't belong in there
because what belongs in there is agile project management that is the context
it also tells you that every single term phrase paragraph that you write about
agile project management has terminology with a specific meaning within that
context
now let's let me give you an example if you want to support threat discussions
among developers working in an agile project management context then you're
probably going to have to use some sort of term that describes the discussion
that can be had on a product backlog item release sprint task whatever
and let's say that the team comes up with the name discussion
no surprise there
so we will have as one of these rectangular boxes in our model something
called discussion but it doesn't mean that forum discussion and post are also
in there that discussion may just be a reference to something that's be managed
in a different context like a collaboration context and in the
collaboration context that's where the nitty-gritty of collaboration takes
place
forums discussions calendars calendar entries the events that fire because of
having it an entry in a calendar so is everybody kind of grasping this that
within the bounded context we are strictly keeping the ideas of a specific
kind of model intact and we're completely rejecting every other kind of
model that we might be tempted to put into this because we're lazy or in a
hurry but instead what we're going to do is purposely move all those other
concepts the context where they belong
ok so
as you're practicing domain-driven design you're going to find that there
are two minds with in DD and most of you probably are given how many are
developers here
all right and how many business people you consider yourself more
businesspeople okay a few you're greatly outnumbered
which doesn't work with DD actually what you're going to find as developers is
that you need the business people you know the people with the thoughts of
business represented by money floating here but you know what they're talking
about what they're thinking about is the success of improving the business model
that's going to make a difference in your enterprise or as a product that
will be offered externally but we also have the techies the techie brain
the guy's the gals who are interested in producing good software
the problem is between these two mindsets is that you know the business
owner is going to be interested in things like this and if we're talking
about scrum again you know they're interested in the scrum type things
product release sprint team product owner volunteer backlog item developers
this might be a bit exaggerated but you know remember that B stands for backlog
item
a stands for product because it was originally called something else
and every time you have a discussion with your business person you've got
this gap going on between you and the gap
is a set of requirements there's actually probably like representative
here a third brain that this is the kind of business analyst type of individual
who is generating these requirements and so you have a translation that's going
on from domain expert the business analyst to developer and depending on
how many business analyst you have and how many developers you have you have a
different idea from the domain expert to the developer you have a different idea
of how this software should work to the point where every time you have a
discussion with the business the business won't know what you're talking
about
and you will not know what the business is talking about so the main goal of
domain driven design then is to unify the mental model we want the domain
expert and the developer to think alike and we're going to do that by using the
ubiquitous language so we also already have a tool for surrounding this
language of the bounded context within that bounded context we have a team
who's developing a model and this model will be governed by the expressions that
we use the conversations that we have and this is our ubiquitous language now
interestingly notice when this feedback loop begins between developers and
business people you might think that it immediately leads to solutions and it it
does lead the solutions but the first thing that happens is questions
the developers start to ask well how do you perceive this working in software
because you're talking about you know physical things the the you know the
real world so to speak but we're dealing with software and sometimes many times
actually the real world doesn't make it nearly as much sense as you know a
projection of of the real world and so how do you perceive that this is
actually going to work in software and then you start having discussions that
lead to breakthroughs that lead to really understanding the great value of
the effort that you're making within this this feedback loop and let me just
give you you know sort of a an interesting example we were we were in
discussion
several domain experts and and architects developers and we were you
know trying to understand this ubiquitous language we were doing
something called event-driven modeling where we were looking at not just the
data within the system but as the data is received and as its manipulated in
some way
how is that data
what are the events around the occurrences within this data
so this was the exercise that we were going through but there was a key domain
expert who was unavailable for our meetings and we had had a couple of you
know one hour sessions or to our sessions that week and we felt that we
weren't really asking for too much out of
the business people we were trying to you know keep our meetings to a minimum
but we did need their feedback on how the software was supposed to function
so one of these business experts would not attend the meeting did not see if
benefit in this and it got to the point where everybody was basically begging
this guy to attend just a portion of the meeting and so after about one and a
half of these meetings
this individual walked in kind of you know disturbed and of course they get me
the DD consultant guide to try to give the elevator speech on why he should be
there and that didn't do any good
so I suggested just sit here for 30 minutes
just sit here for 30 minutes and you don't even have to give us any ideas
I just want you to see what's happening in these discussions and so he agreed to
that and in 30 minutes or less of attending this meeting this guy has the
aha moment and he says you're talking about
and then he uses a business expression that would do for most anyone
experienced with using DD you know what what the light bulb does for you know
most individuals in it and it says this is the name of the core domain that we
as a company failed to develop two years ago but if we had developed this core
domain two years ago we wouldn't be losing two million dollars a year trying
to maintain the data on a daily basis using developers to patch our database
on a daily basis because we didn't understand
we didn't have enough discussions and that is exactly what we're talking about
here
this is where
you know unfortunately many times it's the developers who recognized the need
to have this feedback loop with business people
it's the business people many times who feel way way too engaged and and you
know committed to what they are already doing to get involved in this new
developer DD x right or xdd maybe tee dee dee dee dee dee
I've heard all those DD things so this is what's actually going to be you know
of benefit but as developers now let's switch back to you for for just a moment
is it a language inevitably when we start going through exercises of
modeling and software
what the developers naturally do they naturally draw those boxes with some
lines in between them and put the nouns on there and they say that's the
ubiquitous language but that isn't actually the ubiquitous language if if
we could get just a volunteer to describe to come up here for a moment
and describe your day
from the moment you woke up until now and describe it only with nouns
anybody want to volunteer that to do that you know it starts with alarm clock
and it moves on to
well let's skip that and then nouns are important parts of any language and even
in a context where our context is described your day from when you woke up
until now that's a context
describe your day only announced what if we all know that context and someone
came up here and set alarm clock bathroom shower egg
you know or toast coffee . r da booth
as you were sharepoint whatever you know whatever your day has consisted of we
would all tend to be able to make a little bit of sense of of your day
expressed only announced but the language is far more than nouns and let
me give you an example with scrum
this is linguistic ok
a backlog item may be committed to a sprint
if the back ugh item is not already scheduled for release then it may not be
committed to the sprint when the backlog item is committed to the sprint
we will notify interested parties that's actually linguistic that's you know that
that's a language that's part of a discussion that we can have with people
and as we talk about each of those items we know what we're talking about because
we know the definition of a backlog item release a sprint but there's still some
sort of nebulous stuff in there
think about this for a moment who's actually committing the backlog item to
a sprint
who who does that on the team everyone
maybe or we might have a business rule that says only product owners can commit
backlog items to a sprint
oh that's a problem how many here want your product owner to be able to commit
a backlog item to a sprint any old time they want to
no way
right okay that makes sense
so by asking who does that we've not only improve the language we we're
making up some sort of a business rule may be anybody can
or maybe just the product owner can but if it's the product owner
don't they need some sort of here comes new linguistic expression forum of
team members to approve that this backlog item can be committed to a
sprint
you know that may not be the perfect linguistic terminology to use but it
gets us started and it and it helps us with an idea that one or more developers
will have to allow the product owner to do this and this conversation has
probably taken place in a team meeting of some kind of like a sprint planning
meeting and after that sprint planning meeting a couple of developers voted and
made up this forum of team members that now the product owner can go and commit
this backlog item to a sprint
this has limitless value two teams who perform this because this is the point
where you're really understanding what your software has to do in order for you
to satisfy the users who use it and bring them to the goal that they are
trying to reach
so you need to really focus on a language now to kind of jump back to the
point where we were just a bit ago
what we're going to do is say that this is the actual core domain and this core
domain is the agile project management context are the other concepts that
belong in this model
sure but probably not very many but what happened to all those other sort of
commodity things tenants users permissions
what happened to those what happened to the calendar calendar event the forum
post of discussions
what happened to the time management
we still have a team there we have product owner and team member
what happened to the rest of it well notice that for example user and
permission are gone
that doesn't mean that they don't exist in your enterprise
probably everybody here will use identity and access management of some
kind to manage the users that can sign on to their software and do certain
things with the software
of course you will but what do you think that a product owner and a team member
really are in another bounded context
those are users with a certain role their users with a certain role in our
context our ubiquitous language has told us that product owner and team member
are the users of our software they do things with this software you know every
now and then the word user will no doubt slip out of our of our mouths but in
reality what we really want right now as a team is to talk about product owners
and team members remember after all it's team members who are going to have to
form a quorum of a purple for a backlog item to be committed to a sprint
because the product owner needs that quorum in order to be able to do that if
we were using the term user in the role of where that gets in the way doesn't it
instead we just want to discuss the thing that really fit into this model
but notice a team member is not a team member when they're working on a task
there a volunteer
it's actually the exact same user as a team member and the exact same role of
team member but in this case
according to scrum volunteers volunteer or team members volunteer to work on
tasks so this is the actual core and notice to that discussion is in there
you notice discussion is there but forum and post or not
that's because in this domain will care at all about forums and post
we're just interested in the discussion that takes place between product owners
and team members
that's all that we are interested in so will allow another bounded context to
manage such things
so a basic rule of thumb with domain driven design is use bounded context to
separate models by language right
so when you separate separate by language so you have to ask yourself
then
even though you may have a discussion in your language
do you have a post in your language is it necessary
does it get in the way if forum and post don't belong in your language than no
doubt they belong outside the bounded context if those concepts start to miss
lead the team in their understanding of what is the core that we're working on
what is the most important thing that we need to you know as a team accomplished
within this bounded context then you're wasting your time by putting in
extraneous modeling concepts that actually do not benefit
so what I've been talking about is this fictitious team that I conceptualized
for for the book and in order to help teams and the interesting thing is about
this activation you know
suppose the company is throughout my book and throughout the the workshop we
get to look at these
teams as making the mistakes that we want to avoid
ok that and they make most of the mistakes that everyone makes with DD
when they're first starting out but the story that I've been talking about is
salvation
they are developing as their new core domain and agile project management
context
it's a multi-tenancy problem
so tenants as in you know like people who become tenets of an apartment
building you
you live in an apartment you pay rent on the apartment
actually I'm saying this because some people don't know what a tendency is but
you know think of this as an organization now who's going to
subscribe to certain software applications that salvation is
developing and when a company does this they become a tenant
all right and the early problem thats a salvation experience was the one that
I've just been trying to explain to you to avoid so avoid this kind of situation
where actually their first core domain was a collaboration contact so they were
interested in forum post discussion calendar calendar entry
you know wiki's blogs anything that can help you know basically corporations
fortune companies whatever to elaborate as teams within the organization within
departments across departments and so forth
- training to discuss to mentor to enlighten to support but as they were
developing this model they made that mistake of putting user and permission
basically in a silo right in this application and user in permission were
now tangled actually directly referenced by calendar by calendar entry by forum
by post by the sky
fashion and you know what um most developers would say well we definitely
don't want to develop a silo so we need identity and access management to be
outside this context anyway right
we don't want a silo of users especially not in a SAS environment where you want
as many users as possible to subscribe and use you know various offerings that
you have
well that's true but we could have discovered in the first place that this
didn't belong
not just because of the the silo situation but rather because of
linguistics the language just didn't match because if you're talking about
the language of a forum
you're talking about moderators you're talking about authors you're talking
about participants in a calendar entry or a meeting right
you're talking about the owner of the calendar so as far as the ubiquitous
language is concerned none of these concepts really fit in or I should say
user and permission didn't fit in at all
so this was an early problem that that was discovered and eventually by using
the strategic design parts of DD they were able to discover that
and now let's take a look back at that original you know sort of out of control
big ball of mud model that was starting to form
you know similar to that UML diagram that that went from one end of the
conference table to another
so in the center there is our project are agile project management cord main
the term core is referring to the most important thing thats a Salvation could
be working on at that point in time it doesn't mean that it's actually limited
to just one thing its core because it's at least as important as the other most
important things
however notice what is not in that core domain tenancy users roles
those are not in the core domain there in another bounded context account and
payment there in another bound of context support plan incident in another
bounded context forum calendar and so forth and a collaboration context the
resource manager the time consuming resource the schedule and availability
in another bounded context now chances are good that at least on some of these
contexts
you could download open source or purchase a Microsoft product or someone
else's product to take care of these other contexts for you maybe just with
some integration patterns the use of integration patterns you can integrate
with some purchase software in order to accomplish you know these other five
that contextual representations of features that you need at least support
features but salvation wants to stay focused on what's in the core
this is one of their main offerings
this is what's going to distinguish them
actually this and the collaboration context in the upper right hand corner
those are two of the core domains that's a Salvation should be focused on it
could be that they could develop these other pieces of software as well or they
could acquire them they might even
go into subscription mode with another software as a service company to perform
some of these things
now what each of these things are is a bounded context again abounded context
is a solution space
it's a place where you are actually physically developing the software
conceptualising the model but actually coding that model in c-sharp let's say
we're F sharp and so you want to think of each of these as being for example at
least conceptually a separate visual studio solution within that solution you
would have probably a domain model project and the domain model project
would have the core modeling concepts within it
your web layer and your services layer and so forth could be in a different
place your infrastructure of how how do you actually persist these objects which
will be talking about in the next session will be in a separate model and
so forth
all right let's think of these things then as separate solutions entirely
now when we develop any software especially in an enterprise environment
there's always Brown is anyone here not familiar with brownfield development
what it means ok brownfield development is where you have a legacy system that
you know in essence you could call it a model but the model is is actually more
representative of of what's there because all of us want to think in
abstractions and so we abstract this big ball of mud application or subsystem or
system into concepts that that you know we can think about that we can make
sense of
but when you look inside
it's just a lot of brown and you know it's not pleasant to look at
it's not pleasant to smell but you know what's interesting about this brown you
see that the little glimmer of hope the little glimmer of hope is that green is
growing and so sometimes our DD models are just like the little you know small
areas of green that are growing around the brown but you know what that's what
really matters and fixing the brown is just not going to happen
so how do you develop the green the nice
Chris model that you see here let me ask you this
where is most of the brown in this illustration in this picture
where do you think most of the brown is and just shout it out
you want to its it ok there's a lot of brown spread between the rows so we take
the you know the gift that we get from the cattle or horses on our farm and we
take that gift and we and we spread it between the rows so the green will grow
absolute you know and and it's the same with any enter new enterprise model you
need support from those brown areas around the enterprise or you can't do
your job but you know there's actually a place where where the brown is even more
concentrated
it's it's inside that sort of barn
don't call it a silo silos where you put consumable goods but inside this and at
a distance is the brown and and DD helps you to deal with the brown in this way
you encapsulate it you have stract it
you take from this building
only the brown that you need at any given time and you use it just in the
portions that's necessary between the rows to get your nice green model to
grow and in domain driven design we're going to talk a bit about context
mapping this would be called an anti-corruption layer and Ed because
we're looking at the brown model in the way we want to look at it in our own new
crisp green model
ok so didi can help with that
and again this is what we call context mapping so how does the agile project
management core or bounded context get its notion of product owners team
members
how does it do that how does it get its notion of discussions and milestones for
example in its calendar
well it uses context mapping to map the relationships between the agile project
management core and the Identity and Access context and the collaboration
context it integrates with those systems and any corrupts the data that it gets
back from those for example when it wants to know is some user in some role
as in product owner or team member
scrum team member or scrub product owner then it will take that data but anti
corrupted because it's not going to use user and roll in its own conceptual
model and its model it's going to you
whose product owner and team member
same goes for discussion there may be lots of forums
lots of discussions many posts within a discussion but all that the agile
project management context is interested in is that there is one discussion that
for example a product owns or that a backlog item owns and so in order to map
between these various contexts
we're using simple as simple as possible api integration kinds of of approaches
we're reading data from another system but we're now
anti corrupting that by translating it into the kinds of objects that we like
an hour bounded context and some of these contexts mapping techniques
already named one any corruption layer
there's open host service there's published language those are heavily
used very you know sort of highly applicable ways of of using context
mapping
there are also team aware approaches like partnership like a customer
supplier that help us to understand the team relationships that we have between
teams and the assumptions we can make or must make in order to help our our
project succeed
so there are you know several different contexts mapping approaches that you can
use but like I said some of the more popular ones or ones that you'll tend to
use often are the anti-corruption layer against an open post service and a
published language
those can actually be implemented through rest or some WCF API or
messaging or or something like that
let's talk for a few minutes about architecture now and again
I want to point out that this is roughly speaking a bounded context
ok it's a bounded context because well this is a diagram about architecture but
it's a bounded context because what we have chosen is that in using
domain-driven design we're going to make certain that this architecture
represents a boundary where we're supporting the agile project management
model conceptually inside of this and nothing more
and if you were to name this architecture
it's been named hexagonal but I've drawn it in a circle so it's there's no
hexagon there
some people might call this onion architecture but you know if you if you
want to get away from the shapes that you must draw the architecture in and
just give it a useful name
it's called ports and adapters so the ports are at the outside of the
architecture in this architecture there's actually only an outside and an
inside and at the inside as you see at the top of the inner circle is
application and that inner inner circle is the domain model
ok so we actually create an API of sorts around the domain model we model our
product backlog item release sprint and so forth inside in the core in the heart
of this software
the application is on the is is around that both of those things the
application of the main model are considered the inside this is the stuff
that in essence if you were to port you would you could put this anywhere
ok now i only state that as I'm not I'm not
talking about being a proponent of portability as in portable application
architectures many times that just doesn't work out but I'm just saying
that in principle if you were to think about the parts that port it would be
those parts on the outside though are the adapters there the incoming adapters
like a world wide web browser right or a telephone
mobile phone or some other cloud application that's integrating with you
the lightning bolt represents messaging so if you look at those four areas to
the left hand side of the diagram
those are incoming ports airports that are interacting on their own to
collaborate with this bounded context and on the right hand side on the outer
right hand side are the out put adapters
as in i'm going to store my model my products backlog items releases sprints
and so forth
someplace and perhaps that disc at the top represents sequel server
perhaps some the adapter just below that could represent like a loser
storage tables which is kind of you know key value storage the next adapter might
be an in-memory grid of some time and then finally we have our messaging as an
outgoing messages messages that we produce whereas the messages that we
consume are on the left hand side so the advantage that you have with this kind
of an architecture and using domain-driven design is that you can
actually plug in adapters as you need them
you can test the domain model before the application layer it
this you can test the application layer without the domain model you can test
you know some sort of input device before the application layer exists
you can decide late in the game what kind of storage will we use maybe we
will use sequel server but maybe we'll also use as you were
storage tables for some reason will we need messaging do we need to accept
messaging as part of our contract to the outside world for integration or will we
merely produce messages
so we can make these kinds of decisions as we understand that they are necessary
to make all right so use this ports and adapters kind of architecture to your
advantage
it will allow you to swap and all different kinds of of storage
you know repositories and so forth for your model just a few of the advantages
of using that now here's another major gripe that I have which actually you
know if you're developing software like this
you're you're probably neither using DVD that that would be a great you know a
far stretch but you're actually not even doing
object-oriented programming you see this save customer transactional okay i'm
sorry this is java
I snuck some java in on you but its job of running in the cloud so you don't
know but you know what i started programming in o.o like in the mid to
late eighties time frame and if an object oriented developer were to see a
method name save customer they would naturally asked in the next breath
save the customer from what because save customer would be a behavior that would
actually do some sort of saving act
Lord the customer but in the software that gets written today
this is a procedure that you could write and C sharp or you could write this
procedure in java or whatever but all that you're really doing is taking a
bunch of data represented by strings only and we're just decide we're making
the decision that if the customer does not exist when we try to read it from
the DAO that we're going to create it that's what that means that means if if
the ID doesn't exist yet in the database then it means we want to create the
customer and then we check to see if any of these values are known if they're not
all it means it's optional
so we're not going to set any data on the customer but you know what this is
not a no model this is a data model in a general-purpose language you know this
could just as easily be a sequel but instead we've decided to write it and
let's say C sharp or something
so this is a huge huge problem in the software industry today
not only are we just dealing with data but we aren't even dealing with smart
data
look at all the extraneous properties that we have their customer first name
customer last name street address 12 city state or province postal code
country
aren't those related shouldn't they be formed into a postal address kind of
concept
what about phone number what about email address
these are all just strings how do you know that those strings are correct
because they're not null and this kind of software is what gets in the way of
of producing good software now as you look at this
think about this next model all that we've done is taken that customer
interface and made the behaviour on the customer interface that represent the
kinds of behaviors that we actually intend to perform on the customer and we
also take that extraneous data and we form it into what's called a value
object like postal address like telephone like email address
these are concepts that makes sense to the business and their immutable
concepts because in this case a postal address is just information about where
someone lives or where someone works but look at now
how we are expressing the intention of the business the intention of the
business is that we might change the postal address at some point in time by
just setting the postal address that could be for example a user comes into
the software and they have misspelled the name of the street that they live on
so they changed that postal address and click update
that's where we would just set the postal address but to the business
relocate to may have another meaning
that's very important for example if you are shipping product today for this
customer and they relocate or give you information that they have relocated to
a different postal address that could be very vital information that you need to
inform some other parts of the enterprise about how would you do that
well we're going to talk a little bit later about domain events but it's not
just the fact that you are changing the data and that some piece of software
somewhere needs to be constantly query incurring a customer table to see if
someone's address is different than it used to be
instead
we're going to be proactive and say this customer relocated
we want you to know about this and all of the you know potential side effects
that may have to happen because of that relocation as in packages shipping today
they were just using the website in order to order something and now we want
that package to route to the place where they have relocated to notice too that
you can actually test software like this you can write one or two tests maybe
three tests that proved that this software works whether we're relocating
to or changing the personal name of the customer whatever it happens to be where
as you know you could probably write a hundred different unit test for that
previous customer interface and you may never actually understand that it's
correct or be able to prove that it's correct you
it can only be proven correct and all the ways that you have anticipated that
it should work now another important modeling tool that we have is aggregate
and again at 5pm i'm going to be talking in depth about aggregates and how to
design good aggregates think of aggregate as a special kind of entity
ok we all probably know what entities are it's a uniquely identified a concept
that may change over time
well an aggregate is a globally uniquely identified concept that may change over
time and it has a few very primary kinds of properties about it has what's called
an aggregate route which is and maybe it is an entity and it may be the only
entity that exists or that aggregate route entity may hold on to one or more
other entities and other value and value object or other value objects internally
but the important thing is that there is a transactional boundary around
aggregate type 1 and aggregate type 2 and there's a basic rule of aggregate
that says everything within the aggregate boundary must be consistent at
the end of a transaction but other things in the system do not need to be
consistent until sometime later
so we're talking about both transactional consistency and often the
need for eventual consistency again we'll talk about that in the next
session and finally another tool available for domain driven design a
tactical tool is the main event so how will telling a customer object that it's
relocated to a new postal address be informative to the rest of the
enterprise anything else that needs to know
well if that relocate to method in that previous interface that we looked at
publishes a domain event called customer relocated to and if the correct
interested parties are listening for that event
it means that another aggregate such as who are we going to ship this ordered
product to right now can be updated with the new address just in time
so if this happens quickly within the enterprise within minutes maybe even
potentially within hours then this domain event can help us get the package
that's rolling along
you know the the fulfillment line to actually end up at the new address the
proper address and not have to be redelivered so that's all i have for
this overview of strategic design with DVD and dot net again at five
i'm going to go over aggregates with entity framework
and as ur storage tables using actually event sourcing approach called event
sources
ok any questions briefly
yeah
while describing mission-critical from what your mind
well I think for one thing the bounded context is a context that defines what
is mission critical and what isn't right
so mission-critical applications being what an a in in which bit in which line
of business are you talking about insurance health care what financial so
yeah if you if if you want to understand what your mission critical application
is and and what is most important to the mission
what is critical about the mission then the bounded context is is going to help
you keep that in context and keep everything else out
that's one thing yeah uh-huh
um that's a good question basically at the application level all that you're
really doing is setting up a you know like an execution context for that use
case or user story that you're running right at that time and you don't want to
see any business logic in your application layer at all
so if if you see an if with some sort of business e type thing or something about
data that belongs to the to the model in your application that needs to probably
be migrated to the model but just what you really literally want to do in your
application layer is like load up and aggregate instance from a repository
let's say and just delegate or dispatch immediately to some behavior on the
aggregate and that's as much as you actually want to do other than you know
checking security it is this the right user now an interesting point about that
that user aspect of it or secure
it's on the context for in order to get like a product owner or a team member
through an anti-corruption layer
you're getting two for one on that you're getting the business object that
you need for that use case and if you get back either an exception or null for
example for that product owner
it means no they're not in that role so you're actually getting two for one on
that just taking the step of of acquiring that saying is this user in
this role in another context and if we can't if we don't get that data back and
can't turn it into a product owner object for example then they're you know
they're there they're in the wrong
they're not in the role that they need to be to run this
yeah
yeah so actually what you would typically do is use a domain service as
the front end
oh I'm sorry the question is action
ok so isn't it business logic to to actually come up with a product owner
our team member
let's say is there some business logic to that it's part integration and it's
part business logic and that's why we would we would use a domain service
rather than an application service to actually make that happen so the any
corruption layer is implemented behind the domain service because it is very
much the main logic and so we would get back that product owner from a domain
service to us it
it's just you know this little veneer that out pops a you know a product owner
or team member object but in reality there's a lot of stuff going on
including integration with another system right but out pops this object
that we need and there is some business logic to that yeah so we put it behind
the domain service but the application service calls that domain service and
then loads the aggregate that it's gonna execute some action on and then
dispatches to that aggregate bypassing let's say the product owner that it got
from the domain service
yeah does a domain service have what
uh no no well okay if the domain service that the question is does the domain
service have its own domain model if the domain service is being is is just a
local business logic service then it is performing its business logic on the
core model that it is part of right that that it represents so it's just going to
use the aggregates in its own model if it's in any corruption layer then it's
actually getting data from another system is not in the form that it wants
to use so it has to translate those object representation say there
XML or JSON or whatever it happens to be pro buffer whatever it asked to
translate those into objects that are in its own model
