I thought this would be easy....
For a new project about to start, I'm looking for a simple Windows-based tool for domain-driven modeling - something like "digital CRC's" (Collaboration Responsibility Cards) that would allow me to easily:
define the entities involved
define their properties (and metadata about those properties)
define the links between those entities
I would love to have something that's "dynamic", e.g. if I view the Customer entity, I would like to be able to click on the Orders property and be taken to the details of the Order class to see what's in there. This stuff should ideally be accessible to several devs inside our company, and even to a few key players from the customer's staff - so a web-based solution would be preferred...
It doesn't need to be a full-blown UML, and it should be fairly inexpensive (<= 250$ per dev if ever possible).
Any ideas? I've looked at quite a few tools, which are either:
too big and bulky (full UML support)
far too expensive (can't afford ClearCase licenses......)
too closely tied to a database / storage model already (I don't need an ERM modelling tool - yet)
if you only need a tool for capturing entities, their properties and relationships between them, yet you're not interested in the technical details (relationship type, multiplicity etc), maybe a mind map tool would do the job?
Checkout http://www.mindmeister.com/, you can get free accounts, can share maps with other users, history, relationship between entities etc.
It's not meant for technical diagrams though. I use it for personal stuff, but who knows, might suit your needs.
Related
I would like to know:
how to convert users stories into sequence diagrams?
and what is the most easy diagram to understand (for customer)?
Traditionally, a use case is converted into sequence diagrams (through a "use case realization" collaboration for traceability). User stories are different from use cases in that the latter provide a set of distinct steps to take whereas the former concentrate on a need and reason.
If you were to to take a use case, each of the steps in the use case would be represented by messages in the sequence diagram. The use case actor (the "user" in the user story) would be the initiating timeline and a second timeline would be the "system". You could then iterate on that sequence diagram to extract various system components (thereby building a domain model for your application).
Does that make sense to you?
how to convert users stories into sequence diagrams?
There is no straightforward easy way. There is not enough information as user story is basically one or few sentences of text. Converting use cases to sequence diagrams is easier and can be partially automated
what is the most easy diagram to understand (for customer)?
it depends on who is the customer. In general, overview diagrams, e.g. BPMN style should be easy to read. See my answer to the question "UML diagram for dependency between systems" for some options and useful links
suggested readings
Enterprise Architect video - how to convert use case into a diagram -http://www.sparxsystems.com/resources/demos/use-case-analysis/structured-use-case-scenarios.htm
Enterprise Architect - various ways how to capture requirements and communicate them to stakeholders - http://www.sparxsystems.com/products/ea/requirements.html
Mike Cohn's page (defined the term "user story") about user stories - http://www.mountaingoatsoftware.com/agile/user-stories
Alistair Cockburn's page (defined the term "use case") about use cases - http://alistair.cockburn.us/Use+Cases
Some examples of tools for creation of sequence diagrams: https://www.websequencediagrams.com/, http://creately.com/diagram-type/uml-sequence-diagrams, you can Google out many more examples both free and payed both online and offline
In my opinion, what works best with the customers are not use cases. They are too abstract and complicated even for the most of developers. And when they are finally approved, you're never sure whether the customers actually understood them correctly.
I suggest the mix of UML activity diagrams and user interface prototypes (non UML) as far the best tool to work on this level of analysis with non technical business people.
Activities model their business in an intuitive, easy to understand and clear way.
UI Prototypes as well, so they can see how they business maps to screens.
Behind the curtains, I like to support activities with a formal and accurate domain class model, invisible to customers of course, but open to developers and making a nice technical backbone of the future system.
User stories fit perfectly in this modelling set, you can even make them less formal and more high-level, as the rest will fill the information gap. Sequences can now be build using domain objects, connecting 2 views - customers' and developers'.
I avoid use cases strongly, whenever possible (although I personally like them).
We have to develop a protocol as a interface description between different systems in different companies. The implementations will be made in different languages (not known) by the developers in each company.
However, we want to develop the protocol on a textual description base together. I will have the base copy of the current version and want to send it out to all for comments.
What is a good tool to do so?
At the moment we are using MS Word what leads to several problems:
We need a lot of time for text formatting things.
Its not possible to reference to a datatype in the methods description.
The wording differs from chapter to chapter (different authors) and is hard to align.
Perfect would be:
A tool with a glossary and auto-completion.
References to other items (methods, data types, ...) with active links.
Automatic generation of a human-readable (PDF-) document.
Do you know such a tool?
PS: I did not get Sparx Systems Enterprise Architect doing the job. Maybe also hints for this one?
This is a very big question, since there are many possible aspects you may (should) wish to document in a protocol specification. The two most important ones would be data structures and message sequences, then there's error management, authentication, timing, etc etc.
UML can certainly be used to describe these things, and Enterprise Architect is eminently able to generate versatile documentation from a model - it will definitely help with your reference issues. But first you will have to determine quite strictly how each aspect of the protocol is to be modelled, and from that you will need to construct the necessary EA configuration / adaptation.
In order to get good quality documents out of EA, I recommend generating the documents from an Add-In using the Object Model's DocumentGenerator class as this gives you more flexibility than the traditional RTF generator - for one thing, you can access Word's API in addition to EA's and thus do far more with the document than is possible using EA's API alone.
Without knowing the size or complexity of your protocol, I'd say this would require at the very least a few weeks' work for someone who is experienced in writing EA adaptations. But if the scope of your project is such that there are several companies involved, it is likely to be worth the investment.
I have done a fair bit of analysis and have used a number of tools to capture requirements: user created storyboards, use cases, GUI drawings, GUI prototypes, User stories & scenarios that can be used as acceptance criteria etc.
While each of these have more or less merit, I think there is one important bit missing. These methods can accurately capture how the user interacts with your app., but it is up to programmer to create and develop a “model” that should be reflected in the code.
I have been reading Evan’s DDD lately and he proposes something different. You need to create the domain model together with the domain expert and share it with him. In order to communicate the ideas with the user, in the book he often uses ad-hoc UML inspired drawings.
I wonder if this is the best way to talk about the model with the domain expert. Are there any other tools, besides UML diagrams, that you could use to capture the domain knowledge and use it while you are discussing the domain with your domain expert?
While the final abstraction into a working domain model (and ultimately a stable model) is your, the developer's, job, I do agree that even the set of tools above can be restricting, and limiting yourself or your communications to just UML can make the conversation seem esoteric to the domain expert.
For systems anatomy, try Block Diagram notation tools at http://www.fmc-modeling.org/.
For white/blackboarding and mind-mapping try FreeMind
For associative organization (and coolness) try TheBrain
For quicker/collaborative graphing (sort of new), try LucidChart
And of course, good ol' Dictionary and Thesaurus to always, always strive for the best terminology.
If these seem right-brained to you, remember that modeling is left-brained analysis done by one party on behalf of two. You're not going to get as much with a purely defined linear process as when that is coupled with trial-and-error, free-running style information mining.
The best way is pencil and paper. UML and what not come after this. Start with a DSL (list of vocabulary that is used when talking about the domain). Then you can use that list to determine what is actually what (model, aggregate, action [verb], etc) then you can do associations.
After all that, then do your UML diagrams and go over it with the domain expert. If they understand it then you're golden.
This book covers doing exactly what I said. I recommend at least skimming this book (actually I dont know if you're using .NET). http://www.amazon.com/Professional-Refactoring-ASP-NET-Wrox-Programmer/dp/047043452X/ref=sr_1_1?s=books&ie=UTF8&qid=1306529986&sr=1-1
There are losts of/ tons of tools THAT you can use:
Actor Map
Actor Table
Business Policies
Business Rules
Context Diagram
Decision Table or Decision Tree
Domain Model
Event Table
Process Map
Scenarios
Statechart Diagrams
Use Cases
Mind Maps
..
There are so many long and boring books about each of them. And sometools work at some context "best" and "may failed" at others. There is nothing like "BEST": Context matter.
But the important thing is not the techniques themself: Important one is How you apply them....
.
The trick is how to "Collaborate" with customers-domain experts-end users.
Collaborative-Workshops generally best at many context. The following book does a nice job at this area.
Requirements by Collaboration: Workshops for Defining Needs ,Ellen
Gottesdiener
Check http://ebgconsulting.com/facassets.php
But be carefull DO NOT BE A TEMPLATE ZOMBIE [ which is a general disease in requirements area ]
And you can use even games for making better Collaboration:
Innovation Games: Creating Breakthrough Products Through Collaborative
Play , Luke Hohmann
Domain experts tend to understand sentences better than anything else. That's why I like Object-Role Modeling. A lot of the development relates to graphical methods, but in practice I find it works best to just use the structured sentences.
I personally find most productive way to just sit down and write domain model on-fly while frequently asking yes/no questions to domain expert that sits next to me. this works only if You are fast enough w/ coding.
Also - well constructed (trees should read like sentences) mind maps in ubiquitous language are great way to communicate. Easy to create, share and understand too.
Real world example:
Payment
comments
can be edited
if user is authorized
with role [Role]
can be approved
if user is authorized
if payment is initiated
if payment is not paid yet
if amount does not exceed allowed budget
when approved
remembers that
saves approving date
can be rejected
if something something...
when rejected
forgets planned pay date
resets amount to be paid
(copy from here if You want to see it in text2mindmap tool)
That translates into:
public class Payment{
public virtual void EditComments(string comments){
Authorize<EditPaymentComments>();
CommentsEntered=true;
CommentsEditedBy=User;
CommentsEditedOn=SysDateTime.Now();
Comments=comments;
}
public virtual void Approve(){
EnsureCanBeApproved();
IsApproved=true;
ApprovedOn=SysDateTime.Now();
Raise(new Approved(this));
}
protected virtual void EnsureCanBeApproved(){
Authorize<AcceptPayments>();
ThrowIf(!IsInitiated,
"Payment is not initiated.");
ThrowIf(IsPaid,
"Payment is already paid.");
ThrowIf(ExceedsAllowedBudget(ToBePaid),
"Amount to be paid exceeds allowed budget.");
}
public virtual void Reject(){
EnsureCanReject();
ForgetPlannedPayDate();
ToBePaid=0;
IsInitiated=false;
IsRejected=true;
Raise(new Rejected(this));
}
private void ForgetPlannedPayDate(){
Deadline=DateTime.MinValue;
DeadlineKnown=false;
}
}
There are many good suggestions so far for tools. Try them and use the ones you like, but the key to success is iteration between code and conversation... what Evans calls knowledge crunching. The more you listen to the domain experts, model what you hear in code, then show them the software, get feedback, and tweak the model, the closer you will come to software that solves the problem at hand.
For me, it depends on the domain expert.
For some, it is a matter of sketching a UI on a whiteboard - showing how it would look on screen - then asking questions like: "Can this one exist without that one?", "Do you have situations, where this one is first added later, or are they always there", "Which order would you prefer them filled out?", "Who needs to know what from this screen?"... Usually, the visual aid helps them get into a situation where they can actually answer your questions very precisely.
Others, I can use naive UML (showing aggregates, valuetypes, properties and collections) and they are fine with that.
Really, to me it is quite simple, I start out simple - keep adding techical stuff until they go blank in their eyes - then take back one step. And always have some kind of starting position to get the creative juices flowing. If you're stuck, just watch'em work - "Wait a minute - why did you not record that information?", "Whoa, you did what there?" - to me, the tools are only there to help me, they rarely help the domain expert.
Basically, knowledge crunching with few to no tools beside a pen and paper (and a whiteboard if possible).
What I do is to create use case diagrams for requirements. I can save all needed information at model level. My use case diagram could save almost all the complex needed system I have to model.
I also can reuse the same use case in more than one diagram and still keep its property. Really superb technology.
Concerning domain with UML I nix use case and class diagram element in the same diagram and all add a database profile which allows me to add persistence in my class diagram. This is therefore object modelling with database specifications.
My modelling is really complex, I create my database and can permanently refactor my requirements and immediately my code without loosing my model.
I use it daily and really like it.
Hope this help.
I am on a tight schedule with my project so don't have time to read books to understand it.
Just like anything else we can put it in few lines after reading books for few times. So here i need some description about each terms in DDD practices guideline so I can apply them bit at a piece to my project.
I already know terms in general but can't put it in terms with C# Project.
Below are the terms i have so far known out of reading some brief description in relation with C# project. Like What is the purpose of it in C# project.
Services
Factories
Repository
Aggregates
DomainObjects
Infrastructure
I am really confused about Infrastructure, Repository and Services
When to use Services and when to use Repository?
Please let me know if anyway i can make this question more clear
I recommend that you read through the Domain-Driven Design Quickly book from infoq, it is short, free in pdf form that you can download right away and does its' best to summarize the concepts presented in Eric Evan's Blue Bible
You didn't specify which language/framework the project you are currently working on is in, if it is a .NET project then take a look at the source code for CodeCampServer for a good example.
There is also a fairly more complicated example named Fohjin.DDD that you can look at (it has a focus on CQRS concepts that may be more than you are looking for)
Steve Bohlen has also given a presentation to an alt.net crowd on DDD, you can find the videos from links off of his blog post
I've just posted a blog post which lists these and some other resources as well.
Hopefully some of these resources will help you get started quickly.
This is my understanding and I did NOT read any DDD book, even the holy bible of it.
Services - stateless classes that usually operate on different layer objects, thus helping to decouple them; also to avoid code duplication
Factories - classes that knows how to create objects, thus decouple invoking code from knowing implementation details, making it easier to switch implementations; many factories also help to auto-resolve object dependencies (IoC containers); factories are infrastructure
Repository - interfaces (and corresponding implementations) that narrows data access to the bare minimum that clients should know about
Aggregates - classes that unifies access to several related entities via single interfaces (e.g. order and line items)
Domain Objects - classes that operate purely on domain/business logic, and do not care about persistence, presentation, or other concerns
Infrastructure - classes/layers that glue different objects or layers together; contains the actual implementation details that are not important to real application/user at all (e.g. how data is written to database, how HTTP form is mapped to view models).
Repository provides access to a very specific, usually single, kind of domain object. They emulate collection of objects, to some extent. Services usually operate on very different types of objects, usually accessed via static methods (do not have state), and can perform any operation (e.g. send email, prepare report), while repositories concentrate on CRUD methods.
DDD what all terms mean for Joe the plumber who can’t afford to read books few times?
I would say - not much. Not enough for sure.
I think you're being quite ambitious in trying to apply a new technique to a project that's under such tight deadlines that you can't take the time to study the technique in detail.
At a high level DDD is about decomposing your solution into layers and allocating responsibilities cleanly. If you attempt just to do that in your application you're likely to get some benefit. Later, when you have more time to study, you may discover that you didn't quite follow all the details of the DDD approach - I don't see that as a problem, you proabably already got some benefit of thoughtful structure even if you deviated from some of the DDD guidance.
To specifically answer your question in detail would just mean reiterating material that's already out there: Seems to me that this document nicely summarises the terms you're asking about.
They say about Services:
Some concepts from the domain aren’t
natural to model as objects. Forcing
the required domain functionality to
be the responsibility of an ENTITY or
VALUE either distorts the definition
of a model-based object or adds
meaningless artificial objects.
Therefore: When a significant process
or transformation in the domain is not
a natural responsibility of an ENTITY
or VALUE OBJECT, add an operation to
the model as a standalone interface
declared as a SERVICE.
Now the thing about this kind of wisdom is that to apply it you need to be able to spot when you are "distorting the definition". And I suspect that only with experience (or guidance from someone who is experienced) do you gain the insight to spot such things.
You must expect to experiment with ideas, get it a bit wrong sometimes, then reflect on why your decisions hurt or work. Your goal should not be to do DDD for its own sake, but to produce good software. When you find it cumbersome to implement something, or difficult to maintain something think about why this is, then examine what you did in the light of DDD advice. At that point you may say "Oh, if I had made that a Service, the Model would be so nmuch cleaner", or whatever.
You may find it helpful to read an example.:
I am fairly new to this discussion but I HAVE to ask this question even at the risk of sounding 'ignorant'. Why is it that we now stress so much on 'DDD'. The more I look into 'DDD' the more complex it seems to make my application. Whereas modeling my domain with the database helps keep my application consistent across layers. Then I can use DAL Helpers such as SubSonic or L2S to easily access that model. What is so bad about this? Even in enterprise applications?
Why do we strive to create a new way of modeling our domain when we have a tried and tested one?
I am willing to hear from the purists here.
You can't sell an old methodology, because too many projects failed and too many people know the old methodology anyway. There has to be a new one to market.
If you're doing fine with the old way then use what works. Do pay attention to new stuff, as some really nice ideas come along. But that doesn't mean everything old is bad and stupid. Usually you can incorporate new ideas into the old models to a large degree.
There does come a time to make a move. Like I wouldn't do OOP with structures and function pointers. ;-)
This is actually a really excellent question, and the short answer is "you can." We used to do it that way, and there was a whole area of enterprise (data) modeling. In fact, the common OOD notations evolved from ERD.
What we discovered, however, was that data-driven designs like that had some difficulties, the biggest of them being that the natural structure for a data base doesn't necessarily match well to the natural structure for code.
OOD, to a great extent, derives from the desire to make it easier to find a code structure that has a couple of desirable properties:
it should be easy to think out the design
it should be robust under changes.
The ease to think out design comes originally from Simula, which used what we now think of as "objects" for simulation specifically; it was convenient in simulation to have software entities that correspond to the things you're simulating. It was only later that Alan kay et al at Xerox saw that as a more general structuring method.
The part about robustness under changes had many parents, but one of the most important ones among them was Dave Parnas, you wrote several papers that identified a basic rule for modularization, which I call Parnas' Law: every module should keep a secret, and that secret is a requirements that is likely to change.
It turns out that by combining Parnas' Law with the Simula idea of a "object" as corresponding to something that can be identified with the real world, you tend to get system designs that are more robust under requirements changes than the old way we did things. (Not always, and sometime you have to be crafty, as with the Command pattern. Most objects are nouns, thing that have persistent existence. In the Command pattern, the ideal objects are verbs, things you do.)
However, it also turns out that that structure isn't necessarily a good way to represent the underlying data in a relational database, so we end up with the "object relational impedance mismatch" problem: how to represent the transformation from objectland to database-land.
Short answer: if all you need is a CRUD system that allows users to edit data, just build an Access front-end to your back-end database (or use a scaffolding framework like you mentioned) and call it a day. You should be able to lop off 70% of your budget vs. a domain-driven system.
Long answer: with a data-driven design, what does the implementation of the business model look like? Usually after a couple years of building on new features to your application, you'll find that it's all over the place: tables, views, stored procedures, various application services, code-behind files, presenters/ViewModels, etc. with duplication everywhere. When you're having a conversation with the domain expert about a new feature they are requesting, you are constantly trying to translate from the business language into the language around your implementation, and it just does not translate.
What typically ends up happening is that you are forced to communicate with the business in terms of the implementation of the system, and the implementation becomes the "ubiquitous language" that the business and developers are forced to use when communicating. This has a wide range of consequences. The domain experts in the business start believing that they are experts in the implementation domain, and they start demanding features in terms of implementation rather than the business need they are trying to solve.
Also, you'll find that most data-driven implementations do not follow the "conceptual contours" of the domain, and the components of the system aren't very flexible in how they can be combined together to solve the problem, because they don't map one-to-one with concepts in the business model. When code isn't cohesive, changes and new features may require modifications all over your implementation.
Domain Driven-Design provides tools for making your implementation so closely resemble the business model that it's easy for everyone to speak the language of the business. It allows you to write "executable specifications" that test your implementation, but can actually be understood by your domain experts.