Question

I am just starting out with domain driven design and have a project for my domain which is structured like this:

Domain

• /Entities
• /Boundaries
• /UserStories

As I understand DDD, apart from the boundaries with which the outside world communicates with the domain, everything in the domain should be invisble. All of the examples I have seen of entity classes within a domain have a public access modifer, for example here I have a entity named Message:

public class Message
{        
        private string _text;

        public string Text
        {
            get { return _text; }
            set { _text = value; }
        }

        public Message()
        {

        }

        public bool IsValid()
        {
           // Do some validation on text
        }
}

Would it not be more correct if the entity class and its members were marked as internal so it is only accessible within the domain project?

For example:

internal class Message
{        
        private string _text;

        internal string Text
        {
            get { return _text; }
            set { _text = value; }
        }

        internal Message()
        {

        }

        internal bool IsValid()
        {
           // Do some validation on text
        }
 }

Answer 1

I think there’s a confusion here: the Bounded Context is a concept which defines the context in which a model is valid there aren’t classes actualy named Boundary. Maybe those are objects for anti corruption purposes, but really the Aggregate Root should deal with that or some entry point in the Bounded Context.

I wouldn’t structure a Domain like this, this is artificial, you should structure the Domain according to what make sense in the real world process. You’re using DDD to model a real world process in code and I haven’t heard anyone outside software devel talking aobut Entities or Value Objects. They talk about Orders, Products, Prices etc

Btw that Message is almost certain a value object, unless the Domain really needs to identify uniquely each Message. Here the Message is a Domain concept, I hope you don’t mean a command or an event. And you should put the validation in the constructor or in the method where the new value is given.

In fairness this code is way to simplistc, perhaps you’ve picked the wrong example. About the classes being internal or public, they might be one or another it isn’t a rule, it depends on many things. At one extreme you’ll have the approach where almost every object is internal but implements a public interface common for the application, this can be highly inefficient.

A rule of the thumb: if the class is used outside the Domain assembly make it public, if it’s something internally used by the Domain and/or implements a public interface, make it internal.