I&#39;am unclear as to what the roles and responsibility of the factory class is.  I know enough that the factory class should be resposible for the creation of domain objects (aggregate root) along with its associated entities and value objects.

But what is not clear to me is where the factory &quot;layer&quot; lies with a DDD architecture? Should the factory be calling directly into the repository to get its data or the service library?  

Where does the factory fit into the following framework:&lt;br&gt;
UI &gt; App &gt; Domain &gt; Service &gt; Data

Also, because the factory is the only place allowed for object creation would&#39;nt you get circular references if you wanted to create your objects in your data and service layers?

If the role of the factory class is for object creation then what benefits does the service layer have?

I&#39;ve asked a lot of questions and appreciate any response.  What i&#39;am lacking is a sample application which demonstrates how all the layers in a domain driven design project come together...Is there anything out there?

Domain Driven Design and the role of the factory class

How do I encapsulate the saving of more than one entity in a transactional manner using the repository pattern?  For example, what if I wanted to add an order and update the customer status based on that order creation, but only do so if the order completed successfully?  Keep in mind that for this example, orders are not a collection inside the customer.  They are their own entity.

This is just a contrived example, so I don’t really care whether orders should or should not be inside the customer object or even in the same bounded context.  I don’t really care what underlying technology will be used (nHibernate, EF, ADO.Net, Linq, etc.)  I just want to see what some calling code might look like in this admittedly contrived example of an all or nothing operation.


Transactions in the Repository Pattern

I&#39;m currently faced with a very unusual design problem, and hope that a developer wiser than myself might be able to offer some insight.

Background
-----------
Without being too specific, I&#39;ve been hired by a non-profit organisation to assist with the redevelopment of their legacy, but very valuable (in terms of social value) software. The development team is unlike any I&#39;ve encountered in my time as a software developer, and is comprised of a small number of developers and a larger group of non-programming domain experts. What makes the arrangement unusual is that the domain experts (lets call them content creators), use custom tooling, some of which is based around a prolog expert system engine, to develop web based software components/forms.

The Problem
-----------
The system uses a very awkward postback model to perform logical operations server side and return new forms/results. It is slow, and prone to failure. Simple things, like creating html forms using the existing tooling is *much* more arduous than it should be. As the demand for a more interactive, and performant experience grows, the software developers are finding increasingly that they have to circumvent the expert system/visual tooling used by the content creators, and write new components by hand in javascript. The content creators feel increasingly that their hands are tied, as they are now unable to contribute new components.


Design approach: Traditional/Typical
-----------------------------------
I have been advocating for the complete abandonment of the previous model and the adoption of a typical software development process. As mentioned earlier, the project has naturally evolved towards this as the non-programmatic development tooling has become incapable of meeting the needs of the business. 

The content creators have a very valuable contribution to make however, and I would like to see them focusing on formally specifying the expected behaviour of the software with tools like Cucumber, instead of being involved in implementation. 

Design approach: Non-programmatic
---------------------------------
My co-worker, who I respect a great deal and suspect is far more knowledgeable than me, feels that the existing process is fine and that we just need to build better tooling. I can&#39;t help but feel however that there is something fundamentally flawed with this approach. I have yet to find one instance, either historical or contemporary where this model of software development has been successful. COBOL was developed with the philosophy of allow business people/domain experts to write applications without the need for a programmer, and to my mind all this did was create a new kind of programmer - the COBOL programmer. If it was possible to develop effective systems allowing non-programmers to create non-trivial applications, surely the demand for programmers would be much lower? The only frameworks that I am aware of that roughly fit this model are SAP&#39;s Smart Forms and Microsoft&#39;s Dynamix AX - both of which are very domain specific ERP systems.

DSLs, Templating Languages
---------------------------
Something of a compromise between the two concepts would be to implement some kind of DSL as a templating language. I&#39;m not even sure that this would be successful however, as all of the content creators, with one exception, are completely non technical.

I&#39;ve also considered building a custom IDE based on Visual Studio or Net Beans with graphical/toolbox style tooling.

Thoughts?
----------
Is non-programmatic development a fools errand? Will this always result in something unsatisfactory, requiring hands on development from a programmer? 

Many thanks if you&#39;ve taken the time to read this, and I&#39;d certainly appreciate any feedback.

Is non-programmatic software development feasible?

I keep seeing DDD (Domain Driven Design) being used a lot in articles - I have read the Wikipedia entry about DDD but still can&#39;t figure out what it actually is and how I would go about implementing it in creating my sites?

What is Domain Driven Design (DDD)?

I have been reading about using Command objects to represent use cases that our domain exposes, and Command Handler objects to process those commands.

For example:

- `RegisterUserCommand`
- `RegisterUserCommandHandler`

But it looks exactly the same as having a `RegisterUserService`, where the command object would represent the parameters to the `registerUser()` method.

And of course, if the method had too many parameters, I would end up creating an object to wrap them and that object would be the same as the `RegisterUserCommand`.

So why have a different pattern to represent the same thing? Services are widespread, not Commands (from my experience); what is the difference here that I am missing? In short, why would I use one rather than the other?

What is the difference between Command + CommandHandler and Service?

I have created a POCO model class and a repository class which handles persistence.  Since the POCO cannot access the repository, there are lots of business logic tasks in the repository which doesn&#39;t seem right.  From what I have read, it looks like I need a service layer that sits between the UI consumers and the repository layer.  What I am not sure of is exactly how it is supposed to work...

In addition to the service layer, should there also be a separate business logic layer, or is that the role of the service layer?

Should there be one service per repository?

Is the service layer the only way that the UI can instance the model objects or does the repository provide the new model instance to the service?

Do I put my parameter, model and other validations in the service layer that do things like check to make sure a input is valid and that a item to update exists in the database before updating?  

Can the model, repository and UI all make calls to the service layer, or is it just for the UI to consume?

Is the service layer supposed to be all static methods?

What would be a typical way to call the service layer from the UI?

What validations should be on the model vs the service layer?


Here is some sample code for my existing layers:

    public class GiftCertificateModel
    {
        public int GiftCerticiateId {get;set;}
        public string Code {get;set;}
        public decimal Amount {get;set;}
        public DateTime ExpirationDate {get;set;}

        public bool IsValidCode(){}
    }


    public class GiftCertificateRepository
    {
        //only way to access database
        public GiftCertificateModel GetById(int GiftCertificateId) { }
        public List&lt;GiftCertificateModel&gt; GetMany() { }
        public void Save(GiftCertificateModel gc) { }
        public string GetNewUniqueCode() { //code has to be checked in db }

        public GiftCertificateModel CreateNew()
        {
            GiftCertificateModel gc = new GiftCertificateModel();
            gc.Code = GetNewUniqueCode();
            return gc;
        }              
    }


**UPDATE:** 
I am currently using web forms and classic ADO.NET.  I hope to move to MVC and EF4 eventually.


**UPDATE:** Big thanks to @Lester for his great explanation.  I now understand that I need to add a service layer for each of my repositories.  This layer will be the ONLY way the UI or other services can communicate with the repository and will contain any validations that do not fit on the domain object (eg - validations that need to call the repo)

    public class GiftCertificateService()
    {

        public void Redeem(string code, decimal amount)
        {
            GiftCertificate gc = new GiftCertificate();
            if (!gc.IsValidCode(code))
            {
                throw new ArgumentException(&quot;Invalid code&quot;);
            }
            
            if (amount &lt;= 0 || GetRemainingBalance(code) &lt; amount)
            {
                throw new ArgumentException(&quot;Invalid amount&quot;);
            }

            GiftCertificateRepository gcRepo = new GiftCertificateRepository();
            gcRepo.Redeem(code, amount);
        }

        public decimal GetRemainingBalance(string code)
        {
            GiftCertificate gc = new GiftCertificate();            
            if (!gc.IsValidCode(code))
            {
                throw new ArgumentException(&quot;Invalid code&quot;);
            }

            GiftCertificateRepository gcRepo = new GiftCertificateRepository();
            gcRepo.GetRemainingBalance(code);
        }

        public SaveNewGC(GiftCertificate gc)
        {
            //validates the gc and calls the repo save method
            //updates the objects new db ID
        }

    }

**Questions**

1. Do I add the same (and possibly more) properties to the service as I have on my model (amount, code, etc) or do I only offer methods that accept GiftCertificate objects and direct parameters? 

2. Do I create a default instance of the GiftCertificate entity when the Service constructor is called or just create new ones as needed (eg - for validation methods in the service that need to call validation methods in the entity?  Also, same  question about creating a default repository instance...?

3. I know i expose the functionality of the repo via the service, do I also expose the methods from the entity as well (eg - IsValidCode, etc)?

4. It is ok for the UI to simply create a new GiftCertificate object directly without going through the service (eg - to call parameter validation methods from the entity).  If not, how to enforce it?

5. On the UI layer, when I want to create a new gift certificate, do I call the model/service validations (like IsValidExpirationDate, etc) directly from the UI layer OR do I hydrate the object first, then pass it in to be validated and then return some sort of validation summary back to the UI?  

Also, if I want to Redeem from the UI layer, do I first call the model/service validation methods from the UI to give user feedback and then call the Redeem method which will run the same checks again internally?


**Example for calling service to do a Redeem operation from UI:**

    string redeemCode = RedeemCodeTextBox.Text;

    GiftCertificateService gcService = new GiftCertificateService();
    GiftCertificate gc = new GiftCertificate(); //do this to call validation methods (should be through service somehow?)

    if (!gc.IsValid(redeemCode))
    {
        //give error back to user
    }

    if (gcService.GetRemainingBalance(redeemCode) &lt; amount)
    {
        //give error back to user
    }

    //if no errors
    gcService.Redeem(code,amount);


**Example for creating a new Gift certificate from UI:**

    GiftCertificateService gcService = new GiftCertificateService();
    GiftCertificate gc = new GiftCertificate();

    if (!gc.IsValidExpDate(inputExpDate))
    {
        //give error to user..
    }

    //if no errors...
    gc.Code = gcService.GetNewCode();
    gc.Amount = 10M;
    gc.ExpirationDate = inputExpDate;
    gcService.SaveNewGC(gc);
    //method updates the gc with the new id...


Something feels wrong about way GCs are being created and how the validations are separated between entity/service.  The user/consumer should not have to be concerned with what validations are in which place... advice?

How does a service layer fit into my repository implementation?

I am curious, what are the differences between Domain Driven Design and Model Driven Architecture? I have the impression they have certain similarities.

Could you enlighten me?

Thanks

Domain Driven Design vs Model Driven Architecture

So I got this question from one of the developers in my team: What is domain driven design? I could of course point to the book from Evans but is that actually an answer? 

How would you explain DDD in a few sentences to junior software engineers in your team?

What is domain driven design?

I&#39;m just learning DDD (Eric Evans book is open in front of me) and I&#39;ve come across a problem that I can&#39;t find an answer for. What do you do in DDD when you&#39;re just trying to get a simple list of lookup records?

Ex.

EmployeeID: 123&lt;br /&gt;
EmployeeName: John Doe&lt;br /&gt;
State: Alaska (drop-down)&lt;br /&gt;
County: Wasilla (drop-down -- will be filtered based on state).

For example, let&#39;s say that you have an Employee domain object, an IEmployeeRepository interface and an EmployeeRepository class. This will be used by a UI to show a list of employees and individual details. In the UI, you want to use a drop-down for the State and County where the employee lives. The Available counties will be filtered based on which state was chosen. 
	
Unfortunately, the database tables and the UI look very different. In tblEmployees, it contains State Code=AK and County Code=02130, not the State and County Names.

The old way (before I began this DDD quest) would be pretty straightforward, just create 2 queries and use a DataReader to populate the drop-downs. Underneath the display in the drop-downs is the value, which gets automatically used in form posts.

With DDD, though, I&#39;m not sure how you&#39;re supposed to do this. I first started by creating State and County objects as well repositories and interfaces for the repositories. However, writing 4 classes + 2 interfaces and the plumbing in the hbm.xml files + Employee Business objects seems like overkill for just 2 queries for 2 drop-downs. There has to be a better way, doesn&#39;t there? I&#39;m not changing the records in the State or County tables any time soon and even if I did, it wouldn&#39;t be through this application. So I don&#39;t really want to create business objects for State and County if I don&#39;t have to.

The simplest solution that I see is to just create a helper class with methods that return dictionaries, such as GetStatesAll(), GetState() and GetCounties() and GetCounty(), but that just feels wrong from a DDD perspective. 

Please help. How can I use DDD without overengineering just a couple of simple lookups?

&lt;b&gt;Final Solution&lt;/b&gt;
I think that I finally found my answer through experience, which was to put the GetStates() method into its own Data Access class, though not a repository class. Since I was only doing read-only access, I threw it into a struct DTO. Since the database was small, I threw them altogether into a single class, like Todd below described. 

My conclusions:
&lt;ol&gt;
&lt;li&gt; Lookup tables are NEVER value objects, because lookup tables ALWAYS have an identity. If they didn&#39;t have an identity, you&#39;d have duplicates, which wouldn&#39;t make much sense.
&lt;li&gt; Read-only lookup table can have a repository, but probably don&#39;t need one. The goal of a repository is to reduce complexity by forcing access only through the aggregate. Going through the aggregate provides you with a way to ensure that business rules can be enforced, such as not adding tires if you don&#39;t have a car. 
&lt;li&gt; If you allow CRUD maintenance on the lookup table, then it makes sense for the lookup table to have its own repository.
&lt;li&gt; The fact that I ended up storing the codes as structs doesn&#39;t make them &quot;value types&quot;. Fowler says in POEAA that a struct is a value type. That&#39;s true, structs are immutable, which is why Fowler says that they are &quot;value types&quot;, however I was using them differently. I was using structs as a lightweight way to pass around DTOs that I didn&#39;t ever plan on changing after their initial creation. In truth, the structs that I used did, indeed, have identities, but since they were read-only they worked as structs.
&lt;li&gt;One pattern that I&#39;ve been using that I don&#39;t see much elsewhere is to make primary key fields be immutable. They&#39;re set by the constructor, but they&#39;re read-only (not private accessors) and cannot be changed once the object is created.
&lt;/ol&gt;

What is a practical way to model lookup tables in Domain Driven Design (DDD)?

My repositories deal with and provide persistence for a rich domain model.  I do not want to expose the anemic, Entity Framework data entity to my business layers, so I need some way of mapping between them.

In most cases, constructing a domain model instance from a data entity requires the use of parameterised constructors and methods (since it is rich).  It is not as simple as a property/field match.  AutoMapper could be used for the opposite situation (mapping to data entities) but not when creating domain models.

**Below is the core of my repository pattern.**  

The `EntityFrameworkRepository` class works with two generic types:

 - `TDomainModel`: The rich domain model
 - `TEntityModel`: The Entity Framework data entity

Two abstract methods are defined: 

 - `ToDataEntity(TDomainModel)`: To convert to data entities (for `Add()` and `Update()` methods)
 - `ToDomainModel(TEntityModel)`: To construct domain models (for the `Find()` method).  

Concrete implementations of these methods would define the mapping required for the repository in question.

    public interface IRepository&lt;T&gt; where T : DomainModel
    {
        T Find(int id);
        void Add(T item);
        void Update(T item);
    }

    public abstract class EntityFrameworkRepository&lt;TDomainModel, TEntityModel&gt; : IRepository&lt;TDomainModel&gt;
        where TDomainModel : DomainModel
        where TEntityModel : EntityModel
    {
        public EntityFrameworkRepository(IUnitOfWork unitOfWork)
        {
            // ...
        }

        public virtual TDomainModel Find(int id)
        {
            var entity = context.Set&lt;TEntityModel&gt;().Find(id);

            return ToDomainModel(entity);
        }

        public virtual void Add(TDomainModel item)
        {
            context.Set&lt;TEntityModel&gt;().Add(ToDataEntity(item));
        }

        public virtual void Update(TDomainModel item)
        {
            var entity = ToDataEntity(item);

            DbEntityEntry dbEntityEntry = context.Entry&lt;TEntityModel&gt;(entity);

            if (dbEntityEntry.State == EntityState.Detached)
            {
                context.Set&lt;TEntityModel&gt;().Attach(entity);

                dbEntityEntry.State = EntityState.Modified;
            }
        }

        protected abstract TEntityModel ToDataEntity(TDomainModel domainModel);
        protected abstract TDomainModel ToDomainModel(TEntityModel dataEntity);
    }

**Here is a basic example of a repository implementation:**

    public interface ICompanyRepository : IRepository&lt;Company&gt;
    {
        // Any specific methods could be included here
    }

    public class CompanyRepository : EntityFrameworkRepository&lt;Company, CompanyTableEntity&gt;, ICompanyRepository
    {
        protected CompanyTableEntity ToDataEntity(Company domainModel)
        {
            return new CompanyTable()
            {
                Name = domainModel.Name,
                City = domainModel.City
                IsActive = domainModel.IsActive
            };
        }

        protected Company ToDomainModel(CompanyTableEntity dataEntity) 
        {
            return new Company(dataEntity.Name, dataEntity.IsActive)
            {
                City = dataEntity.City
            }
        }
    }

**Problem:**

A `Company` might be composed of many `Departments`.  If I want to eagerly load these from the `CompanyRepository` when fetching a `Company` then where would I define the mapping between a `Department` and a `DepartmentDataEntity`?

I could provide more mapping methods in the `CompanyRepository`, but this will soon get messy.  There would soon be duplicated mapping methods across the system.

What is a better approach to the above problem?

Repository pattern and mapping between domain models and Entity Framework

I&#39;m (re)designing large-scale application, we use multi-layer architecture based on DDD.

We have MVC with data layer (implementation of repositories), domain layer (definition of domain model and interfaces - repositories, services, unit of work), service layer (implementation of services). So far, we use domain models (mostly entities) across all layers, and we use DTOs only as view models (in controller, service returns domain model(s) and controller creates view model, which is passed to the view).

I&#39;v read countless articles about using, not using, mapping and passing DTOs. I understand that there&#39;s no any definitive answer, but I&#39;m not sure if it&#39;s ok or not returning domain models from services to controllers. If I return domain model, it&#39;s still never passed to the view, since controller always creates view-specific view model - in this case, it seem legit. On the other hand, it doesn&#39;t feel right when domain model leaves business layer (service layer). Sometimes service needs to return data object that wasn&#39;t defined in the domain and then we either have to add new object to the domain that isn&#39;t mapped, or create POCO object (this is ugly, since some services return domain models, some effectively return DTOs).

The question is - if we strictly use view models, is it ok to return domain models all the way to controllers, or should we always use DTOs for communication with service layer? If so, is it ok to adjust domain models based on what services need? (Frankly I don&#39;t think so, since services should consume what domain has.) If we should strictly stick to DTOs, should they be defined in service layer? (I think so.) Sometimes it&#39;s clear that we should use DTOs (e.g., when service performs lot of business logic and creates new objects), sometimes it&#39;s clear that we should use just domain models (e.g., when Membership service returns anemic User(s) - it seems it wouldn&#39;t make much sense to create DTO that is the same as domain model) - but I prefer consistency and good practices.

Article https://stackoverflow.com/questions/12874328/domain-vs-dto-vs-viewmodel-how-and-when-to-use-them (and also some other articles) is very similar to my problem, but it doesn&#39;t answer this question(s). Article https://stackoverflow.com/questions/19932876/should-i-implement-dtos-in-repository-pattern-with-ef is also similar, but it doesn&#39;t deal with DDD.

Disclaimer: I don&#39;t intend to use any design pattern only because it exists and is fancy, on the other hand, I&#39;d like to use good design patterns and practices also because it helps designing the application as a whole, helps with separation of concerns, even though using particular pattern isn&#39;t &quot;necessary&quot;, at least at the moment.

Should services always return DTOs, or can they also return domain models?

In Domain Driven Design, there seems to be [lots][1] of [agreement][2] that Entities should not access Repositories directly. 

Did this come from Eric Evans [Domain Driven Design][3] book, or did it come from elsewhere?
 
Where are there some good explanations for the reasoning behind it?
  
edit: To clarify: I&#39;m not talking about the classic OO practice of separating data access off into a separate layer from the business logic - I&#39;m talking about the specific arrangement whereby in DDD, Entities are not supposed to talk to the data access layer at all (i.e. they are not supposed to hold references to Repository objects)

update: I gave the bounty to BacceSR because his answer seemed closest, but I&#39;m still pretty in the dark about this. If its such an important principle, there should be some good articles about it online somewhere, surely?

update: March 2013, the upvotes on the question imply there&#39;s a lot of interest in this, and even though there&#39;s been lots of answers, I still think there&#39;s room for more if people have ideas about this.

  [1]: http://thinkddd.com/blog/2009/03/02/the-specification-pattern/
  [2]: https://stackoverflow.com/questions/827670/is-it-ok-for-entities-to-access-repositories/827693#827693
  [3]: http://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215

DDD - the rule that Entities can&#39;t access Repositories directly

Can somebody please explain (in succinct terms) what exactly is domain driven design? I see the term quite a lot but really don&#39;t understand what it is or what it looks like. How does it differ from non-domain driven design?

Also, can somebody explain what a Domain Object is? How does domain differ from normal objects?

What is Domain Driven Design?

I&#39;m using NHibernate to persist my domain objects.
To keep things simple I&#39;m using an ASP.NET MVC project as both my presentation layer, and my service layer.

I want to return my domain objects in XML from my controller classes. After reading some posts here on Stack Overflow I gather DTOs are the way to go. However, I&#39;ve also come across posts talking about the ViewModel.

My question: Are Data Transfer Objects and ViewModels the same thing? Or is a ViewModel a kind of sub pattern of a DTO?

DTO = ViewModel?

I have just started reading DDD. I am unable to completely grasp the concept of Entity vs Value objects.. Can someone please explain the problems (maintainability, performance.. etc) a system could face when a Value object is designed as a Entity object? Example would be great...

Value vs Entity objects (Domain Driven Design)

What is the difference between Data Access Objects (DAO) and Repository patterns? I am developing an application using Enterprise Java Beans (EJB3), Hibernate ORM as infrastructure, and Domain-Driven Design (DDD) and Test-Driven Development (TDD) as design techniques.

What is the difference between DAO and Repository patterns?

I was under the impression they are all basically the same.  Are model objects also the same?


Right now, in my architecture, I have:

    class Person 
    {

        public string PersonId;        
        public string Name;
        public string Email;

        public static bool IsValidName() { /* logic here */ }
        public static bool IsValidEmail() { /* logic here */ }
    }


    class PersonService
    {
        private PersonRepository pRepository;

        PersonService()
        {
            pRepository = new PersonRepository();
        }

        public bool IsExistingEmail(string email)
        {
            //calls repo method to see if email is in db
        }


        public Person GetPerson(email)
        {
            return pRepository.Get(email);
        }


        public void SavePerson(Person p)
        {
            if (Person.IsValidEmail(p.Email) &amp;&amp; !IsExistingEmail(p.Email)
            {
                pRepository.Save(p);
            }
        }

    }


    class PersonRepository
    {
        public void Save(Person p)
        {
            //save to db
        }

        public Person Get(string email)
        {
            //get from db
        }

        public bool IsExistingEmail(string email)
        {
            //see if email in db
        }

    }


So which of the above classes are `POCO`, `Domain Object`, `Model object`, `entity`?

What is the difference between domain objects, POCOs and entities?

I&#39;ve read Eric Evan&#39;s book and am reading Vaughn Vernon&#39;s book now. I&#39;m in the second chapter where he talks about subdomains and bounded context and am thoroughly confused now.

From what I was able to distill, there should be a 1:1 relationship between a BC and an SD. However, I read in other places that this isn&#39;t necessarily the case.

Can someone explain to me the relationship between a BC and SD?

Confused about Bounded Contexts and SubDomains

One part of domain-driven design that there doesn&#39;t seem to be a lot of detail on, is how and why you should isolate your domain model from your interface. I&#39;m trying to convince my colleagues that this is a good practice, but I don&#39;t seem to be making much headway...

They use domain entities where ever they please in the presentation and interface layers. When I argue to them that they should be using display models or DTOs to insulate the Domain layer from the interface layer, they counter that they don&#39;t see the business value in doing something like that, because now you have a UI object to maintain as well as the original domain object.  


So I&#39;m looking for some concrete reasons I can use to back this up. Specifically:

1. Why should we not use domain objects in our presentation layer?    
(if the answer is the obvious one, &#39;decoupling&#39;, then please explain why this is important in this context)
2. Should we use additional objects or constructs to isolate our domain objects from the interface?

Why should I isolate my domain entities from my presentation layer?

Every article found in the Internet on using ViewModels and utilizing Automapper gives the guidelines of the &quot;Controller -&gt; View&quot; direction mapping. You take a  domain model along with all Select Lists into one specialized ViewModel and pass it to the view. That&#39;s clear and fine.  
The view has a form, and eventually we are in the POST action. Here all the Model Binders come to the scene along with *[obviously] another* View Model which is *[obviously] related* to the original ViewModel at least in the part of naming conventions for the sake of binding and validation.

**How do you map it to your Domain Model?**

Let it be an insert action, we could use the same Automapper. But what if it was an update action? We have to retrieve our Domain Entity from the Repository, update it&#39;s properties according to the values in the ViewModel and save to the Repository.

**ADDENDUM 1 (9th of February 2010):** Sometimes, assigning Model&#39;s properties is not enough. There should be taken some action against Domain Model according to the values of View Model. I.e., some methods should be called on Domain Model. Probably, there should be a kind of an Application Service layer which stands between Controller and Domain in order to process View Models...

----------

**How to organize this code and where to place it to achieve the following goals?**

 - keep controllers thin
 - honor SoC practice
 - follow Domain-Driven Design principles
 - be DRY
 - to be continued ...

How to map View Model back to Domain Model in a POST action?

I currently have a repository for just about every table in the database and would like to further align myself with DDD by reducing them to aggregate roots only.

Let’s assume that I have the following tables, `User` and `Phone`.  Each user might have one or more phones.  Without the notion of aggregate root I might do something like this:

	//assuming I have the userId in session for example and I want to update a phone number
	List&lt;Phone&gt; phones = PhoneRepository.GetPhoneNumberByUserId(userId);
	phones[0].Number = “911”;
	PhoneRepository.Update(phones[0]);

The concept of aggregate roots is easier to understand on paper than in practice.  I will never have phone numbers that do not belong to a User, so would it make sense to do away with the PhoneRepository and incorporate phone related methods into the UserRepository?  Assuming the answer is yes, I’m going to rewrite the prior code sample.

Am I allowed to have a method on the UserRepository that returns phone numbers? Or should it always return a reference to a User, and then traverse the relationship through the User to get to the phone numbers:

	List&lt;Phone&gt; phones = UserRepository.GetPhoneNumbers(userId);
	// Or
	User user = UserRepository.GetUserWithPhoneNumbers(userId); //this method will join to Phone

Regardless of which way I acquire the phones, assuming I modified one of them, how do I go about updating them?  My limited understanding is that objects under the root should be updated through the root, which would steer me towards choice #1 below.  Although this will work perfectly well with Entity Framework, this seems extremely un-descriptive, because reading the code I have no idea what I’m actually updating, even though Entity Framework is keeping tab on changed objects within the graph.

	UserRepository.Update(user);
	// Or
	UserRepository.UpdatePhone(phone);

Lastly, assuming I have several lookup tables that are not really tied to anything, such as `CountryCodes`, `ColorsCodes`, `SomethingElseCodes`.  I might use them to populate drop downs or for whatever other reason.  Are these standalone repositories?  Can they be combined into some sort of logical grouping/repository such as `CodesRepository`?  Or is that against best practices.


Reducing Repositories to Aggregate Roots

I&#39;m learning about Domain Driven Design, however there are some practical issues that are confusing to me that I think seeing some good samples might clear up.

Does anyone know of some good working code samples that do a good job of modelling basic DDD concepts?

Particularly interested in

 - An illustrative Domain Model
 - Repositories
 - Use of Domain/Application Services
 - Value Objects
 - Aggregate Roots

Where do I find some good examples for DDD?

Let&#39;s take a simple &quot;Account Registration&quot; example, here is the flow:

- User visit website
- Click &quot;Register&quot; button and fill form, click &quot;Save&quot; button
- MVC Controller: Validate UserName uniqueness by reading from ReadModel 
- **RegisterCommand: Validate UserName uniqueness again (here is the question)**

Of course, we can validate UserName uniqueness by reading from ReadModel in MVC controller to improve performance and user experience. However, **we still need to validate the uniqueness again in RegisterCommand**, and obviously, we should NOT access ReadModel in Commands. 

If we do not use Event Sourcing, we can query the domain model, so that&#39;s no a problem. But if we&#39;re using Event Sourcing, we are not able to query domain model, so **how can we validate UserName uniqueness in RegisterCommand?** 

**Notice:** User class has an Id property, and UserName is not the key property of User class. We can only get the domain object by Id when using event sourcing.

**BTW:** In the requirement, if the entered UserName is already taken, the website should show error message &quot;Sorry, the user name XXX is not available&quot; to the visitor. It&#39;s not acceptable to show a message, say, &quot;We are creating your account, please wait, we will send the registration result to you via Email later&quot;, to the visitor.

Any ideas? Many thanks!

**[UPDATE]**

A more complex example:

**Requirement:**

When placing an order, the system should check the client&#39;s ordering history, if he is a valuable client (if the client placed at least 10 orders per month in the last year, he is valuable), we make 10% off to the order.

**Implementation:**

We create PlaceOrderCommand, and in the command, we need to query the ordering history to see if the client is valuable. But how can we do that? We shouldn&#39;t access ReadModel in command! As Mikael [said][1], we can use compensating commands in the account registration example, but if we also use that in this ordering example, it would be too complex, and the code might be too difficult to maintain.


  [1]: https://stackoverflow.com/a/9496198/290617

CQRS Event Sourcing: Validate UserName uniqueness

I read about DDD and Access Control, and I found some contradiction between the following two opinions:

 - &quot;security concerns should be handled outside the domain&quot;
 - &quot;access control requirements are domain specific&quot;

I am looking for a best practice about this. So where should I put the access control logic by domain driven design, and how should I implement it?

(To be more specific by DDD + CQRS + ES.)

I think it should be somewhere near to the business logic, for example a user story could be something like this:

&gt; The user can edit his profile by sending an user name, a list of hobbies, cv, etc...

Based on the user story we implement the domain model and the services, for example:

    UserService
    	editProfile(EditUserProfileCommand command)
    		User user = userRepository.getOneById(command.id)
    		user.changeName(command.name)
    		user.changeHobbies(command.hobbies)
    		user.changeCV(command.cv)
    
    UserRepository
    	User getOneById(id)
    		
    User
    	changeName(String name)
    	changeHobbies(String[] hobbies)
    	changeCV(String cv)
    	
This is okay, but where is the `HIS profile` part of the story?

This is obviously attribute based access control, because we should write a rule something like this:

    deny all, but if subject.id = resource.owner.id then grant access

But where should we enforce this rule, and how should we implement it?

Access Control in Domain Driven Design

I haven&#39;t really seen any examples, but I assume that they are saved inside the containing entity table within the database.

Ie. If I have a Person entity/aggregate root and a corresponding Person table, if it had a Value Object called Address, Address values would be saved inside this Person table!

Does that make sense for a domain where I have other entities such as Companies etc. that have an Address? 

(I&#39;m currently writing a project management application and trying to get into DDD)



How are Value Objects stored in the database?

I&#39;m new to DDD, and I&#39;m trying to apply it in real life. There is no questions about such validation logic, as null check, empty strings check, etc - that goes directly to entity constructor/property. But where to put validation of some global rules like &#39;Unique user name&#39;?

So, we have entity User

    public class User : IAggregateRoot
    {
       private string _name;

       public string Name
       {
          get { return _name; }
          set { _name = value; }
       }

       // other data and behavior
    }
    

And repository for users

    public interface IUserRepository : IRepository&lt;User&gt;
    {
       User FindByName(string name);
    }

Options are:

 1. *Inject repository to entity*
 2. *Inject repository to factory*
 3. *Create operation on domain service*
 4. *???*

And each option more detailed:

**1 .Inject repository to entity**

I can query repository in entities constructor/property. But I think that keeping reference to repository in entity is a bad smell.

    public User(IUserRepository repository)
    {
        _repository = repository;
    }

    public string Name
    {
        get { return _name; }
        set 
        {
           if (_repository.FindByName(value) != null)
              throw new UserAlreadyExistsException();

           _name = value; 
        }
    }

Update: We can use DI to hide dependency between User and IUserRepository via Specification object.

**2. Inject repository to factory**

  I can put this verification logic in UserFactory. But what if we want to change name of already existing user?

**3. Create operation on domain service**

  I can create domain service for creating and editing users. But someone can directly edit name of user without calling that service...

    public class AdministrationService
    {
        private IUserRepository _userRepository;

        public AdministrationService(IUserRepository userRepository)
        {
            _userRepository = userRepository;
        }

        public void RenameUser(string oldName, string newName)
        {
            if (_userRepository.FindByName(newName) != null)
                throw new UserAlreadyExistException();

            User user = _userRepository.FindByName(oldName);
            user.Name = newName;
            _userRepository.Save(user);
        }
    }

**4. ???**

**Where do you put global validation logic for entities?**

Thanks!

Where to put global rules validation in DDD

I am trying to learn domain-driven design (DDD), and I think I got the basic idea. But there is something confusing me.

In DDD, are the persistence model and domain model different things? I mean, we design our domain and classes with only domain concerns in mind; that&#39;s okay. But after that when we are building our repositories or any other data persistence system, should we create another representation of our model to use in persistence layer?

I was thinking our domain model is used in persistence too, meaning our repositories return our domain objects from queries. But today, I read this post, and I&#39;m a little confused:

*[Just Stop It! The Domain Model Is Not The Persistence Model][1]*

If that&#39;s true what would be the advantage of having separate persistence objects from domain objects?

  [1]: https://blog.sapiensworks.com/post/2012/04/07/Just-Stop-It!-The-Domain-Model-Is-Not-The-Persistence-Model.aspx


DDD - Persistence Model and Domain Model

I have been reading about domain driven design and how to implement it while using code first approach for generating a database. From what I&#39;ve read and researched there are two opinions around this subject:

1. Have 1 class that serves both as a domain model and a persistence model

2. Have 2 different classes, one implementing the domain logic and one used for a code-first approach

Now I know opinion 1) is said to simplify small solutions that do not have many differences between the domain and persistence models but I think it breaks the single responsibility principle and by that introduces a lot of issues when an ORM&#39;s conventions interfere with DDD.

What is a surprise to me is there are numerous code examples of how to implement opinion 1). But a haven&#39;t found a single example of how to implement opinion 2) and how to map the 2 objects. (Probably there are such examples but I failed to find a C# one)

So I tried to implement an example on my own but I am not sure if that&#39;s a good way to do it.

Let&#39;s say I have a ticketing system and tickets have expiration date. My domain model will look like this:

    /// &lt;summary&gt;
    /// Domain Model
    /// &lt;/summary&gt;
    public class TicketEntity
    {
        public int Id { get; private set; }

        public decimal Cost { get; private set; }

        public DateTime ExpiryDate { get; private set; }

        public TicketEntity(int id, decimal cost, DateTime expiryDate)
        {
            this.Id = id;
            this.Cost = cost;
            this.ExpiryDate = expiryDate;
        }

        public bool IsTicketExpired()
        {
            if (DateTime.Now &gt; this.ExpiryDate)
            {
                return true;
            }
            else
            {
                return false;
            }
        }
    }

The persistence model using Entity Framework as ORM will look almost the same but as the solution grows this might not be the case

    /// &lt;summary&gt;
    /// ORM code first Persistence Model
    /// &lt;/summary&gt;
    public class Ticket
    {
        [Key]
        public int Id { get; set; }

        public decimal Cost { get; set; }

        public DateTime ExpiryDate { get; set; }
    }

Everything looking great so far. Now what I am not sure about is which is the best place to get a `Ticket` persistence model from the repository and how to map it to the `TicketEntity` domain model

I have done this in an application/service layer.

    public class ApplicationService
    {
        private ITicketsRepository ticketsRepository;

        public ApplicationService(ITicketsRepository ticketsRepository)
        {
            this.ticketsRepository = ticketsRepository;
        }

        public bool IsTicketExpired(int ticketId)
        {
            Ticket persistanceModel = this.ticketsRepository.GetById(ticketId);
            TicketEntity domainModel = new TicketEntity(
                persistanceModel.Id,
                persistanceModel.Cost,
                persistanceModel.ExpiryDate);

            return domainModel.IsTicketExpired();
        }
    }

My questions are:

1. Are there any reasons opinion 1) would be preferred to opinion 2) other than speeding up development and reusing code.

2. Are there any issues in my approach of mapping the models? Is there something I missed that would bring up issues when a solution grows?

Having Separate Domain Model and Persistence Model in DDD

I had seen some books(e.g *programming entity framework code first Julia Lerman*) define their domain classes (POCO) with no initialization of the navigation properties like:

&lt;!-- language: c# --&gt;

    public class User
    {
        public int Id { get; set; }
        public string UserName { get; set; }
    
        public virtual ICollection&lt;Address&gt; Address { get; set; }
        public virtual License License { get; set; }
    }
some other books or tools (e.g *Entity Framework Power Tools*) when generates POCOs initializes the navigation properties of the the class, like:

&lt;!-- language: c# --&gt;

    public class User
    {
        public User()
        {
            this.Addresses = new IList&lt;Address&gt;();
            this.License = new License();
        }
        public int Id { get; set; }
        public string UserName { get; set; }
    
        public virtual ICollection&lt;Address&gt; Addresses { get; set; }
        public virtual License License { get; set; }
    }

&lt;h3&gt;Q1: Which one is better? why? Pros and Cons?&lt;/h3&gt;

**Edit:**

&lt;!-- language: c# --&gt;

    public class License
    {
        public License()
        {
            this.User = new User();
        }
        public int Id { get; set; }
        public string Key { get; set; }
        public DateTime Expirtion { get; set; }

        public virtual User User { get; set; }
    }

&lt;h3&gt;Q2: In second approach there would be stack overflow if the `License` class has a reference to `User` class too. It means we should have one-way reference.(?) How we should decide which one of the navigation properties should be removed?&lt;/h3&gt;

EF codefirst : Should I initialize navigation properties?

How do you deal with validation on complex aggregates in a domain driven design? Are you consolidating your business rules/validation logic?

I understand argument validation and I understand property validation which can be attached to the models themselves and do things like check that an email address or zipcode is valid or that a first name has a minimum and maximum length.

But what about complex validation that involves multiple models? Where do you typically place these rules &amp; methods within your architecture? And what patterns if any do you use to implement them?

Validation in a Domain Driven Design

I&#39;m seriously confused about the concept of the &#39;Model&#39; in MVC.  Most frameworks that exist today put the Model between the Controller and the database, and the Model almost acts like a database abstraction layer.  The concept of &#39;Fat Model Skinny Controller&#39; is lost as the Controller starts doing more and more logic.

In DDD, there is also the concept of a Domain Entity, which has a unique identity to it.  As I understand it, a user is a good example of an Entity (unique userid, for instance).  The Entity has a life-cycle -- it&#39;s values can change throughout the course of the action -- and then it&#39;s saved or discarded.

The Entity I describe above is what I thought Model was supposed to be in MVC?  How off-base am I?

To clutter things more, you throw in other patterns, such as the Repository pattern (maybe putting a Service in there).  It&#39;s pretty clear how the Repository would interact with an Entity -- how does it with a Model?

Controllers can have multiple Models, which makes it seem like a Model is less a &quot;database table&quot; than it is a unique Entity.

**UPDATE:** [In this post][1] the Model is described as something with knowledge, and it can be singular or a collection of objects.  So it&#39;s sound more like an Entity and a Model are more or less the same.  The Model is an all encompassing term, where an Entity is more specific.  A Value Object would be a Model as well.  At least in terms of MVC.  Maybe???

So, in very rough terms, which is better?

No &quot;Model&quot; really ...

    class MyController {
        public function index() {
            $repo = new PostRepository();
            $posts = $repo-&gt;findAllByDateRange(&#39;within 30 days&#39;);
            foreach($posts as $post) {
                echo $post-&gt;Author;
            }
        }
    }

Or this, which has a Model as the DAO?

    class MyController {
        public function index() {
            $model = new PostModel();
            // maybe this returns a PostRepository?
            $posts = $model-&gt;findAllByDateRange(&#39;within 30 days&#39;);
            while($posts-&gt;getNext()) {
                echo $posts-&gt;Post-&gt;Author;
            }
        }
    }

Both those examples didn&#39;t even do what I was describing above.  I&#39;m clearly lost.  Any input?


  [1]: http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html

DDD and MVC: Difference between &#39;Model&#39; and &#39;Entity&#39;

Can someone explain the difference between domain and application services by providing some examples? And, if a service is a domain service, would I put the actual implementation of this service within the domain assembly and if so, would I also inject repositories into that domain service? Some info would be really helpful.

Domain Driven Design: Domain Service, Application Service

**Any ideas / feedback are welcome :)** 

I run into a problem in how to **handle business logic** around my **Doctrine2 entities** in a big **Symfony2 application**. (Sorry for the post length)

After reading many blogs, cookbook and others ressources, I find that :

 - Entities might be used only for data mapping persistence (&quot;anemic model&quot;),
 - Controllers must be the more slim possible,
 - Domain models must be decoupled from persistence layer (entity do not know entity manager)

Ok, I&#39;m totally agree with it, but :
**where and how handle complex bussiness rules on domain models ?**

 
----------


A simple example
----------------

**OUR DOMAIN MODELS :**

&gt;  - a **Group** can use **Roles**
&gt;  - a **Role** can be used by different **Groups**
&gt;  - a **User** can belong to many **Groups** with many **Roles**,

In a **SQL** persistence layer, we could modelize these relations as :

![enter image description here][1]

**OUR SPECIFIC BUSINESS RULES :**

&gt;  - **User** can have **Roles** in **Groups** *only if Roles is attached to the Group*.
&gt;  - If we detach a **Role R1** from a **Group G1**, all *UserRoleAffectation with the Group G1 and Role R1 must be deleted*

**This is a very simple example, but i&#39;d like to kown the best way(s) to manage these business rules.**


----------


Solutions found
---------------

**1- Implementation in Service Layer**

Use a specific Service class as  :

    class GroupRoleAffectionService {
    
      function linkRoleToGroup ($role, $group)
      { 
        //... 
      }
    
      function unlinkRoleToGroup ($role, $group)
      {
    	//business logic to find all invalid UserRoleAffectation with these role and group
    	...
    
    	// BL to remove all found UserRoleAffectation OR to throw exception.
    	...
    
    	// detach role	
    	$group-&gt;removeRole($role)
    	
    	//save all handled entities;
    	$em-&gt;flush();	
    }

 - (+) one service per class / per business rule
 - (-) API entities is not representating to domain : it&#39;s possible to call `$group-&gt;removeRole($role)` out from this service.
 - (-) Too many service classes in a big application ?


----------


**2 - Implementation in Domain entity Managers**

Encapsulate these Business Logic in specific &quot;domain entities manager&quot;, also call Model Providers :

    class GroupManager {
    
    	function create($name){...}
    
    	function remove($group) {...}
    
    	function store($group){...}
    	
    	// ...
    
    	function linkRole($group, $role) {...}
    
    	function unlinkRoleToGroup ($group, $role)
    	{
    	
    	// ... (as in previous service code)
    	}
    
    	function otherBusinessRule($params) {...}
    }

 - (+) all businness rules are centralized
 - (-) API entities is not representating to domain : it&#39;s possible to call $group-&gt;removeRole($role) out from service...
 - (-) Domain Managers becomes FAT managers ?


----------


**3 - Use Listeners when possible**

Use symfony and/or Doctrine event listeners :

    class CheckUserRoleAffectationEventSubscriber implements EventSubscriber
    {
        // listen when a M2M relation between Group and Role is removed
        public function getSubscribedEvents()
        {
            return array(
                &#39;preRemove&#39;
            );
        }
    
       public function preRemove(LifecycleEventArgs $event)
       {
    	// BL here ...
       }


----------


**4 - Implement Rich Models by extending entities**

Use Entities as sub/parent class of Domain Models classes, which encapsulate lot of Domain logic. But this solutions seems more confused for me.


----------


**For you, what is the best way(s) to manage this business logic, focusing on the more clean, decoupled, testable code ?** Your feedback and good practices ? Have you concrete examples ?

*Main Ressources :*

 - https://stackoverflow.com/questions/14400120/symfony-managing-entities
 - https://stackoverflow.com/questions/8021730/symfony2-doctrine-having-to-put-business-logic-in-my-controller-and-duplicatin
 - https://stackoverflow.com/questions/12179812/extending-doctrine-entity-in-order-to-add-business-logic
 - http://iamproblematic.com/2012/03/12/putting-your-symfony2-controllers-on-a-diet-part-2/
 - http://l3l0.eu/lang/en/2012/04/anemic-domain-model-problem-in-symfony2/
 - https://leanpub.com/a-year-with-symfony

  [1]: http://i.stack.imgur.com/yhs3t.png


Doctrine Entities and business logic in a Symfony application

To take advantage of the wide range of query methods included in `java.util.stream` of Jdk 8 I am attempted to design domain models where getters of relationship with `*` multiplicity (with zero or more instances ) return a `Stream&lt;T&gt;`, instead of an `Iterable&lt;T&gt;` or `Iterator&lt;T&gt;`.

My doubt is if there is any additional overhead incurred by the `Stream&lt;T&gt;` in comparison to the `Iterator&lt;T&gt;`?

So, is there any disadvantage of compromising my domain model with a `Stream&lt;T&gt;`?

Or instead, should I always return an `Iterator&lt;T&gt;` or `Iterable&lt;T&gt;`, and leave to the end-user the decision of choosing whether to use a stream, or not, by converting that iterator with the `StreamUtils`?

**Note** that returning a `Collection` is not a valid option because in this case most of the relationships are lazy and with unknown size.

Iterator versus Stream of Java 8

In my project using DDD methodology.

The project has the aggregate(entity) Deal. This aggregate has many of use cases.

For this aggregate I need to create a rest api.

With standard: create and delete no problem.

1) **CreateDealUseCase**(name, price and many another params);


    POST /rest/{version}/deals/
    { 
       &#39;name&#39;: &#39;deal123&#39;,
       &#39;price&#39;: 1234;
       &#39;etc&#39;: &#39;etc&#39;
    }

2) **DeleteDealUseCase**(id)

    DELETE /rest/{version}/deals/{id}

But what to do with the rest of the use cases?
 
 - HoldDealUseCase(id, reason);
 - UnholdDealUseCase(id);
 - CompleteDealUseCase(id, and many another params);
 - CancelDealUseCase(id, amercement, reason);
 - ChangePriceUseCase(id, newPrice, reason);
 - ChangeCompletionDateUseCase(id, newDate, amercement, whyChanged);
 - etc(total 20 use cases)...

What are the solutions?

1) **Use verbs**:

    PUT /rest/{version}/deals/{id}/hold
    { 
       &#39;reason&#39;: &#39;test&#39;
    }

But! Verbs can not be used in the url(in REST theory).

2) **Use the completed state**(which will be after the the use case):

    PUT /rest/{version}/deals/{id}/holded
    { 
       &#39;reason&#39;: &#39;test&#39;
    }

Personally for me it looks ugly. Maybe I&#39;m wrong?

3) **Use 1 PUT request for all operations:**

    PUT /rest/{version}/deals/{id}
    { 
       &#39;action&#39;: &#39;HoldDeal&#39;,
       &#39;params&#39;: {&#39;reason&#39;: &#39;test&#39;}
    }

    PUT /rest/{version}/deals/{id}
    { 
       &#39;action&#39;: &#39;UnholdDeal&#39;,
       &#39;params&#39;: {}
    }

It is difficult to handle in the backend.
Moreover, it is difficult to document. Since 1 action has many different variants of requests, from which is already dependent on specific responses.


All solutions have significant drawbacks.


I have read many articles about the REST on the internet. Everywhere only a theory, how to be here with my specific problem?


Rest API and DDD

Googling &quot;What kind of applications is DDD suitable for?&quot; gave me the following answer: 

&gt; Probably 95% of all software applications fall into the “not so good for using DDD” categories. (see [the article][1])

So what is all the fuss about?!?

The application I am working on is *mainly* data-centric but still contains some business logic and rules to be applied. Would it be waste of time to start applying DDD techniques? Am I better off using a more conventional Data Access Layer, a model of POCOs and a Business Logic Layer? Or to state it differently - what is a sound alternative to DDD?

  [1]: http://devlicio.us/blogs/casey/archive/2009/02/18/ddd-what-kind-of-applications-is-it-suited-to.aspx

Is DDD a waste of time?

I am learning about DDD so apologies if my question is naive. I think I need to use Local Data Transfer Object in order to display data to the users as a lot of properties are not part of any of Entity / Value Objects. 

However, I am not sure where this DTO should be implemented - in a Domain Layer or in an Application Service Layer. The DTO implementation seems part of the Domain, but it means that when I create a collection of DTOs in the Service Layer and pass it to a Presentation Layer, I have to reference Domain Layer in  Presentation Layer, which seems wrong. 

What is the correct way to implement DTO using DDD principles?

DDD - which layer DTO should be implemented

I&#39;m looking for some in depth end-to-end CQRS examples with a reasonable set of unit tests.

Also, if anyone knows of some CQRS screencasts as well it would be extremely handy.

I&#39;m already aware of these examples

 - [CQRS Info][1]
 - [Super Simple CQRS][2]


  [1]: http://dddcqrs.com/examples/
  [2]: http://codebetter.com/gregyoung/2010/08/31/super-simple-cqrs-example/

All Domain Driven-Design Solutions on Gang of Coders

Total of 38 Domain Driven-Design Solutions