understanding domain driven design

What is DDD ? Actually I've always developed code in a SOA type of way. I prefer overall architecture as SOA and I know SOA and DDD are two conflicting styles :P


Anyway today i got chance to review code based on DDD. So I have started reading DDD. Still I am unable to completely grasp the concept of Entity vs Value objects. ;-)


I am interested in

1. An illustrative Domain Model
2. Repositories
3. Use of Domain/Application Services
4. Value Objects
5. Aggregate Roots

If you can help then it would be appreciable. 

Well i am looking for how fit SOA and DDD together ? well we can create a domain model that encapsulates domain concepts, and expose entry points into that model via services.

Maybe the problem we can face is that create services like "UpdateOrder" which takes an order entity and tries to update this in a new session?

We should try to avoid that kind of services and instead break those down to smaller atomic commands.

Each command can be exposed as an operation, or you could have a single service operation that receives groups of commands and then delegate those to command handlers.

Well you can read more from web .. here are few good links.

https://github.com/superlogical/Paramore/blob/master/Ignorance/theRules.txt

http://www.domaindrivendesign.org/books/index.html#DDD

Finally summarizing all important key role of DDD.

• Only use one level of indentation per method
• Don't use the else keyword
• Wrap all primitives and strings
• Use only one dot per line
• Unless explicitly using a fluent interface over an OO model
• Don't abbreviate
• Keep all entities small (no more than 50 lines)
• Don't use a class with more than two instance variables
• Use first class collections
• Don't use any getters/setters/properties
• On a class, it's fine to do this with a data object, such as a DTO
• Don't give a data object behavior
• But don't build an illogical model, if a data object needs behavior, make a class

Ending my post with following :P enjoy :-)

I was once asked what my personal motto is. Funnily enough, I had never really decided on one, but I guess it would be:-

“Choose a job you love and you will never have to work a day in your life”

--Confucius

But if you really dig, you’ll find that this line describes best:

“You aren’t remembered for doing what is expected of you”

--Perfect.

Principles of the MVC Design Pattern

The MVC paradigm is a way of breaking an application, or even just a piece of an application's interface, into three parts: the model, the view, and the controller. MVC was originally developed to map the traditional input, processing, output roles into the GUI realm:-

Input --> Processing --> Output
Controller --> Model --> View

Note that the model may not necessarily have a persistent data store (database), such as when it deals with a control on a GUI screen.

Model

• A model is an object representing data or even activity, e.g. a database table or even some plant-floor production-machine process.
• The model manages the behavior and data of the application domain, responds to requests for information about its state and responds to instructions to change state.
• The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.
• The model is the piece that represents the state and low-level behavior of the component. It manages the state and conducts all transformations on that state. The model has no specific knowledge of either its controllers or its views. The system itself maintains links between model and views and notifies the views when the model changes state. The view is the piece that manages the visual display of the state represented by the model. A model can have more than one view.

View

• A view is some form of visualisation of the state of the model.
• The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application.
• The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented.
• The view is responsible for mapping graphics onto a device. A view typically has a one to one correspondence with a display surface and knows how to render to it. A view attaches to a model and renders its contents to the display surface.

Controller

• A controller offers facilities to change the state of the model. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate.
• A controller is the means by which the user interacts with the application. A controller accepts input from the user and instructs the model and view to perform actions based on that input. In effect, the controller is responsible for mapping end-user action to application response.
• The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application they appear as HTTP GET and POST requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
• The controller is the piece that manages user interaction with the model. It provides the mechanism by which changes are made to the state of the model. below is an example of MVC pattern implementation .