I have an assignment for school, where I have to create a domain model of a specific e-commerce site that delivers complete grocery bags to people's homes. (http://www.linasmatkasse.se/)
It's quite basic. Chose a bag, create account (with info), pay.
My question is, what exactly should be included in the model (in general)? In other words, where does the lines of the domain end? For instance, should delivery and suppliers be included? They aren't technically part of the website itself, by still play a role.
Thanks in advance!
What is domain
Let us take some theme/subject. It could be grocery delivery, satellites, swallows observations, anything. Let us name this theme "AAA"
domain model for AAA is a "profi IT" word for model for AAA. That's all.
All elements specific to AAA that you'll set in your model, belong to domain. I don't know, why the old good word theme is not used. It is a pity. But the term is already accepted.
So, delivery and suppliers are in your domain. And also much more specific words belonging to grocery. And to bags. And to people's homes - addresses, drive ways in and out - everything that is relevant to your theme.
The domain sets your vocabulary. And that one is really important - you should use the vocabulary used by your clients and not to invent new words, such as "domain" for "theme" :-)
And first you should define your Use case diagram, later- State machine diagram, Deployment diagram, Component diagram, Communication diagram, Sequence/Activity/Time/Interaction Overview diagrams, and at last - class, object and composite structure diagrams. You needn't make all of them, but SOME are necessary.
Every entity that models an entity in reality is a part of the domain. In your example, delivery and suppliers should be a part of the domain model. Basically any entity that has a defined behavior should be modeled as a part of the domain. Many times it seems like the domain model components aren't a part of the website and this is actually normal, the front-end is a way of viewing the domain model, it doesn't need to expose everything within the domain.
I usually find it easy to think about what entities are logical components of the business model in the real world and I only remove one if I find that it is redundant, unnecessary or can be encapsulated within another entity.
About the entities that are not the part of IT system
Do not ignore the pure human operations. On the contrary. Put them here, only their use cases will connect not actor-(sub)system, but actor-actor. And seeing them is very good for better planning the system as a whole. When ignoring them it is impossible to create a system good for user. The IT system is an integral component of the larger system, and we are creating the larger one really, with planning the support, processes, exchange of info, divisions and dependencies.
Too often had I problems with programmers who are blind to anything out of IT system border. And often it is impossible to make them think out of these borders. As a result, the system is blind to the real needs of the user, too. So we have that sad picture of user-hating software.
It is very useful to start to study the problem/domain/theme from entities that are out of the IT system, and to create firstly the diagram, that considers IT system as merely one of many blocks.
Related
Im new to learn DDD concept and i cant understand something.
1-What difference between Context Map and Bounded Context and SubDomain?
2-How to recognize relation between Bounded Context ?
As said in the comment, this is a wide subject, and very important in DDD. It is the strategic part of DDD. Anyway I will try to answer your questions with an overall explanation:
DDD is about understanding and distilling the domain of the problem we want to solve. It is a continuous process of learning about the domain, talking to the domain experts. All people (developers, business people, etc) speak the same language. This language is used everywhere (conversations, documentation, source code, ...). It is called the Ubiquitous Language (UL).
The problem domain may have different areas of functionality, which would be domains too. They are the subdomains. So a subdomain is a subset of the problem domain. It is like splitting the problem into smaller subproblems, and a subdomain would be the domain of a subproblem. There are 3 kinds of subdomains:
Core: The point of distillation is to discover the subdomain that has value for the business, i.e., the one that will make your product better than others of the same kind. Such subdomain is the "core subdomain". For example, in "project management", the "task assignement" would be core.
Supporting: It is specialized in some business aspect that helps the core functionality. For example, in "project management", a "calendar" (for marking tasks delivery dates).
Generic: Functionality that maybe needed by any kind of application. For example, authentication and authorization of users.
Subdomains belong to the problem space.
To solve the problem, you model the subdomains, and you create bounded contexts (BCs). In practice, a BC is an autonomous application that contains the software model of a subdomain. A BC has its own UL. It is the context on which a term of the UL has a meaning. UL and BCs are the most important things in DDD. UL drives the BCs identification.
Ideally, you should align 1:1 the subdomains of the problem space with the BCs of the solution space, i.e., you should have a BC for each subdomain.
A team can develop one or more BCs, but a BC should be developed by just one team.
BCs belong to the solution space.
Context Map: It is a drawing that shows the BCs, and the relationships among them. Every relationship is classified in one of the following patterns:
Partnership
Shared Kernel
Customer-Supplier
Conformist
Anticorruption Layer
Open Host Service
Published Language
Separate Ways
Big Ball of Mud
Recognizing which pattern to apply in a relationship it will depend on the particular case you have. Some things that you have to consider are:
The 2 teams collaborate together.
One of the teams doesn't care about the other one.
The teams can negotiate.
The teams are independent.
Changes on a model (upstream) affects to the other model (downstream).
As #Augusto mentioned, this is a couple of chapters in the blue book, but here goes.
The domain model is found in the business rules and how people talk but a simplification of it is captured in code. Certain naming is consistent and the necessary invariants are enforced in the model.
A bounded context is mostly conceptual (might be a namespace, module, project in code as well...). It is the intention to keep a domain model consistent within it. So within the context, a certain ubiquitous language is used. And a model need only serve the needs of THAT context. It is the boundary in which the model can be used. In terms of recognizing these relationships? Some might be subtle but most are not. At least some people in the team will want to "avoid duplication" by unifying the model... so that is a clear indication that there is a relationship. Names are often the same or similar... or could be the same but one is better suited to one domain and another to another domain.
A context map is a bit more of a project management tool. It is a map of how different contexts (and the models within) relate to each other. In an Ordering Domain in an e-commerce system you may have a product. It would lead to A LOT of complication trying to have a unified Product in a model that spanned Ordering, Payments, Content for the website and Inventory domains (for example). So each of those domains should have a separate model. The context map is a diagram and related documentation that relates these bounded contexts together since there would be relationships and translation of data across from one model to the next, as an order flows through the system.
The last element you asked about is a subdomain. Here you probably are referring to a generic subdomain. Personally, I think the name is a little confusing. It makes it seem like a subset of the model. Maybe this is on purpose but I generally think of them as their own domain, just one that is not central to the business's proposition. For instance, if the aforementioned e-commerce company was known for its same day or next day delivery, then they probably shouldn't buy an off-the-shelf solution to inventory and shipping management. On the other hand, if they were focusing on a market that just wanted the cheapest deal but didn't mind waiting a few days, then that would be a perfect candidate for a generic subdomain.
My DDD glossary which has plenty of links at the bottom to more detailed articles.
If you are serious about learning this subject and can get your hands on some books:
Domain-driven Design by Eric Evans
Implementing Domain-driven Design by Vaughn Vernon
Domain-driven Design made functional by Scott Wlaschin (my favourite)
I am wondering how granular should a domain event be?
For example I have something simple, like changing the firstName, the secondName and the email address on a profile page. Should I have 3 different domain events or just a single one?
By coarse grained domain events when I add a new feature, I have to create a new version of the event, so I have to add a new event type, or store event versions in the event storage. By fine grained domain events I don't have these problems, but I have too many small classes. What do you think, what is the best practice in this case?
What's the problem with many classes? Really, why so many devs are afraid of having too many classes? You define as many classes as needed.
A domain event signals that the domain changed in a certain way. It should contain all the relevant information and it should be taken into consideration the fact that an event is also a DTO. You want clear events but it's up to the developer to decide how granular or generic an event is.
Size is not a concern, however if your event 'weights' 1 MB maybe you have a problem. And the number of classes is not a domain event design criteria.
I can agree with MikeSW's answer, but applying SRP during the modeling, you can end up with small classes, which is not a problem at all.
According to Greg Young the domain events should always express something that the user does from a business perspective. For example if the user has 2 reasons to change her phone number PhoneNumberChanged, and this information can be important from a business perspective, then we should create 2 event types PhoneNumberMigrated, PhoneNumberCorrected to store technically the same data. This clearly violates DRY, but that is not a problem, because SRP can override DRY in these cases as it does by sharing aggregates and their properties (most frequently the aggregate id) between multiple bounded contexts.
In my example:
I have something simple, like changing the firstName, the
secondName and the email address on a profile page.
We should ask the following: why would the user want that, has it any importance from the perspective of our business?
her account was stolen (security, not business issue)
she moved to another email address
she got married
she hated her previous name
she gave the account to somebody else on purpose
etc...
Well, if we have dating agency services then logging divorces can have probably a business importance. So if this information is really important, then we should put that it into the domain model, and create an UserProbablyDivorced event. If none of them are important, then we can simple say, that she just wanted to change her profile page, we don't care why, so I think in that case both UserProfileChanged or UserSecondNameChanged events can be acceptable.
The domain events can be in 1:1 and in 1:n relation with the commands. By 1:1 relation they name is usually the same as of the commands, but in a past tense. For example ChangeUserProfile -> UserProfileChanged. By 1:n relation we usually split up the behavior which the command represents into a series of smaller domain events.
So to summarize, it is the domain developer's decision how granular the domain events should be, but it should by clearly influenced from a business perspective and not just from a modeling a data schema perspective. But I think this is evident, because we are modeling business and not just data structure.
I have started reading few chapters of the blue book and have read the first three chapters of red book (Implementing Domain Driven Design). I have a two questions:
(1) Can a sub-domain have more than one bounded context? I am particularly looking at the example in Implementing Domain Driven Design book where there is a forecasting sub-domain sort of coupled/overlap with inventory. (Apologies if you have not read the book, but the idea is that there is a strong overlap between the two bounded contexts).
(2) How do I organize my project solution structure (I am using .net), are there any examples of real world projects that I can look at? Should I create folders namely sub-domain, core-domain, generic-domain and then specify the modules under it? I am struggling on how best to define my structure so that it shows the onion/hexagonal layers is in place.
Thanks in advance.
Yes. The Domain is composed from multiple sub domains (if it is complex enough) and each are in fact a group of bounded contexts. The Domain itself can be considered a bounded context (BC) from the app point of view.
A BC doesn't mean that it contains an unique model, but a specific representation of the business concept. So you can have a Book definition in multiple BC but in each, the definition is slightly different, ranging from full details to just an id. So the Book from Inventory is different than a Book from Sales for example. It matters how that BC understands a concept.
The resulting model is valid only in that BC, although it can have the same name as the model from another BC. But that's what namespaces are for.
There isn't a recipe for that, everyone structure their projects how they see fit. But most of the time you'll have at least one Domain project and UI, Persistence, Infrastrcuture projects. I think that the best structure depends on the app and on how the developers thinks so the way I do things might not be the optimum way for you. In a nutshell, structure the app as it makes sense for you.
What are DDD recommendations for inter-domain referencing design?
Should I try to connect them as "Matryoshka" (put one into another) or it is better to create upper-level "inter-domain" business service?
P.S. Crossing this smooth water, I was unable to find anything useful to read in the Internet, and have started thinking that for this kind of things exist better term than "inter-domain referencing"... Am I right?
DETAILS:
I have two models/business services.
Semantically first domain (A) is CRM with sell/maintenance process for our goods, second domain (B) is "design" data of our goods. We have two view points on our goods: from seller perspective and from engineer perspective.
Actually each model is effective ORM (Object-Relational Mapping) tool to the same database.
There are some inter-domain activities e.g. validations (e.g. sometimes we can sell things to smb. only if some engineering rules are valid).
From developer's point of view I have two clear possibilities (reference B in A or create new cross reference domain/service C ). But from designer perspective I am lost in understanding what kind of Business Service I have when I compose business logic from two different domains.
As far as I know, DDD has no strict rules for 'inter-domain' referencing. At the end of the day your domain model will have to reference basic Java or .NET classes. Or it may reference specialized date/time or graph library (aka 'Generic Domain').
On the other hand DDD has a concept of Bounded Context. And it has quite a few patterns that can be applied when you work at the boundaries of the system. For example 'Anticorruption Layer' can be used to isolate you from legacy system. Other integration styles can be used depending on how much control you have over external code, team capabilities etc.
So there is probably no need to introduce artificial glue layer if you just dealing with two subdomains in one Bounded Context. Might also be worth reading Part 4 of DDD book (Strategic Design).
UPDATE:
Based on the information you provided, it looks like you only have one Bounded Context. You don't seem to have 'linguistic clashes' where the same word have two different meanings. Bounded Context integration patterns are most likely not applicable to your situation. Your Sales domain can reference Products domain directly. If you think of Products domain being more low-level and Sales being high level you can use Dependency Inversion Principle. Define an interface like ProductCompatiblityValidator in Sales and implement it in Products domain. And then inject the actual implementation at the application layer. This way you will not have a direct reference from Sales to Products.
In addition to what Dmitry has already said...
I think of any code that crosses bounded contexts as application layer code. I would have that application layer code reference domain types from both contexts (and their repositories) but not have two domains reference each other. I think it's OK to have business logic in an application layer if it specifically crosses domain boundaries and is unit-testable.
If you really have a hierarchy, then it would be OK to have the the more concrete subdomain reference the more abstract domain. However, I would be careful if this causes you to need to have domain objects reference repositories of any type. Pulling objects out of of a repository is rarely a true domain concept. Referencing repositories is best done in an application layer that sits a layer above the domain model.
Of course this is all as much art as science. I'd try modeling a thin slice of your application a couple different ways and see what friction you run into with each approach.
Does it make sense to make subsets of an Entity if you consider their usage in the application differently? IE. I take my entity and define a new entity with only some of the attributes of the first. Now I have 2 Entities that overlap but are used differently but ultimately persist in same datatable. These Entities will be accessed through different repositories...
I am only starting to learn about DDD myself, so if I am wrong please comment and let me know. Here are my thoughts though:
If the entity is going to be accessed through a different repository, I think it deserves its own class. Additionally, the bits that overlap now may not overlap in the future, and if you use a shared base class, you will probably be more likely to try adapting things at that point, which will dirty up your domain.
If the two classes are part of separate sub-domains, they probably should be separate. My thoughts are based around parts of an example I remember hearing in Rob Connery's interview on Hanselminutes. A product has several properties that are important to consumers (pricing, description, etc), and several properties that are important to warehouse personnel (location in the warehouse, weight, dimensions, etc). The implication to me in that episode was that the two products should be defined separately in the domain, instead of being defined once and shared.
If by "usage in the application" you mean you'll display different parts in different views, then I'd suggest you use a presentation pattern like Fowler describes in his Presentation Model (or if your developing a WPF app you can use the more WPF-specialized version called Model-View-ViewModel (MVVM)).
But if you by "usage" mean that you'll use different attributes of the entity in different sub-domains or part of your domain, then I agree with Chris; You'd probably be better off breaking them into different entities. The reason being that in your domain model you should reflect how the entity is used in that specific (sub)domain. And if you're using different parts of the entity under different circumstances, they probably have different meanings in these settings which again should be reflected in the naming of the entities. And if it were me, I'd probably make one repository for each of the entities. Having a 1:1 mapping between entities and repositories seems to make sense in most cases as far as I've experienced. But then again; just like Chris, Rob Conery and 90% of the developers trying to do DDD; I'm fairly new to the DDD-game and so my experiences might be overruled by someone more experienced :)