我是新来的DDD和我的工作我的第一个项目，这是一个在线的高尔夫郊游的注册过程。我的要求是pretty的简单。用户注册踏青，并可以选择添加一个四人。他们还可以用赞助的消息和一些其他的东西一个洞，但我想第一个散列我们四人的东西。

I'm new to DDD and I am working on my first project, which is for an online golf outing registration process. my requirements are pretty simple. users register for the outing and can optionally add a foursome. they can also sponsor a hole with a message and a few other things, but i want to hash our the foursome stuff first.

所以，我的第一次，虽然我总包含注册实体，四人值对象（其中包含一个队名和4名玩家的值对象）。

so, my first though my aggregate contains the a registration entity, foursome value object (which contains a team name and 4 player value objects).

在设计API时，我在想下面的伪code：

when designing the api, i'm thinking the following pseudo code:

Registration reg = new Registration();

Foursome foursome = reg.CreateFoursome("My Team");

foursome.Player1.Assign("John Doe", 5, ShirtSize.XL);

reg.Register();

我的问题是，总的内部组件之一，被暴露给客户端code，所以我会打开我的自我弥补的问题？这个简单的设计或替代API的任何瑕疵？

My question is, one of the internal components of the aggregate is being exposed to the client code, so am I opening my self up for issues? any flaws with this simple design or alternative apis?

任何帮助将是巨大的，因为我在分析瘫痪状态吧！

any help would be great as i am in a state of analysis paralysis right now!

感谢

推荐答案

对于第一枪这是不坏。在开始设计的时候不要太挂在小细节是很重要的。你花了多少时间，担心设计的稳健性将是主要项目的重要的因素。你会不断地学习，因为你建立，并随着时间的推移，你的旧code将需要重构，使新的细节。

For a first shot it isn't bad. It is important when starting design not to get too hung up on the small details. How much time you spend worrying about the robustness of the design is going to be primarily a factor of the project's importance. You will continually learn as you build, and over time, your old code will require refactoring to enable new details.

就拿，你福森类我认为有四个球员。难道你不是有一个Team类具有尺寸限制，使得玩家收集，可以限制在这个数字的球员呢？应该有一个播放器类（或者说是PLAYER1？类型）？

Take for instance, your FourSome class I assume has four players. Could you instead have a Team class which has a Size constraint, such that a Players collection could be constrained to that number of players? Should there be a Player class (or perhaps that is the type of Player1?)?

在回答这些问题将影响对你的系统的可扩展性。

The answers to these questions will have implications toward the extensibility of your system.

我鼓励你去你的每一个场景写入测试（你可以使用用户故事，或使用的情况下也是如此，但开发商愿意写code），并为你写的测试，填写注册，球员，和四人/ Team类的实现，使测试成功。当你扩大你的系统，你的测试会发生变化，所以将你的设计。

I encourage you to write each of your scenarios into tests (you could use user stories or use cases too, but developers like to write code), and as you write the tests, fill in the Registration, Player, and Foursome/Team class implementation to make the tests succeed. As you expand your system, your tests will change, and so will your design.

后添加1：

领域驱动设计旨在成为一个方法来开发类和数据结构的应用程序将使用使得其模式问题域。在你的情况，你正在使用一个高尔夫比赛登记制度。因此，你想想这可能使这样一个系统中的实体，你可能会描述如何将队长提供了注册登记他/她的团队（包括其他玩家）。注册可能是一个事件，其本身可能有详细信息，如主办单位，承办单位，等等。正如你看到的，每一个大写的名字成为你的实体（类）。至少对你的设计初稿。当你发现你的类之间的关系的详细信息，尤其是在它们之间如何相互作用（一个玩家加入到一个团队），你会充实你的类的方法。

Domain driven design is intended to be an approach to developing the classes and data structures your application will use such that it "models" the problem domain. In your case, you are working with a Golf Outing Registration system. Therefore, as you think about the entities which might make up such a system, you might describe how a Team Captain registers his/her Team (including other Players) by providing his Registration. The registration might be for an Event, which itself may have details such as Organizer, Sponsor, etc. As you see, each of the "capitalized" names become your entities (classes). At least for the first draft of your design. As you discover more information about the relationships between your classes, especially in how they interact (a Player is added to a team), you will flesh out the methods of your class.

在这个过程中，你可以在不经意间引入设计上的缺陷。例如，一个福森是，在技术上，一个类型队局限于四个玩家。是否有意义从小组派生类并设置四名球员的限制，还是有意义穿上团队的约束？这是...您的业务规则，你确定的设计决策。它是一个错误采取一种方法比其他？时间会告诉我们，因为你需要，以扩大该系统不断的重构。

During this process you can inadvertently introduce design flaws. For instance, a FourSome is, technically, a type of Team limited to four players. Does it make sense to derive a class from Team and set a limit of four players, or does it make sense to put a constraint on Team? That is a design decision determined by... your business rules and you. Is it a mistake to take one approach over the other? Time will tell, as you will need to constantly refactor in order to expand the system.

您将在您的设计过程中，可能使你的设计过程中更容易找到很多的模式，而是一种新的设计通常不具备的经验来识别何时使用它们。如果你这样做，荣誉给你。你不会找到一个完美的设计非常您第一次设计。我还回头看（现年15岁）的设计我认为是真棒，和动摇我的头，在我年轻的活力。

You will find many patterns during your design process that may make your design process easier, but a new designer typically does not have the experience to recognize when to use them. If you do, kudos to you. You will not find a perfect design the very first time you are designing. I still look back (15 years now) at designs I thought were awesome, and shake my head at my youthful exuberance.

您应该描述您的问题（给自己或在纸上）。强调名词。他们是你的候选类。讲一个故事，与系统中每个用户交互，和动词应该让你开始朝着什么样的方法是对每一个类。避免使用注册，以完成所有的工作，但单独的类的地方是适当的责任。举例来说，你可以添加一个球员到一个团队，或者你可以有一个玩家加入自己团队。确定在何处的责任在于要引导（但不是决定）的战略调整计划，其中包括设计指导。

You should describe your problem (to yourself or on paper). Underline the nouns. They are your candidate classes. Tell a story for each user interaction with the system, and the verbs should get you started toward what the methods are on each class. Avoid using the Registration to do all the work, but separate the responsibility of the classes to where it is appropriate. For instance, you can add a player to a team, or you can have a player add itself to a team. Determining where that responsibility lies should be guided (but not dictated) by the SRP, among other design guidance.

最后，在设计上没有正确的答案。你根据我的丰富的设计经验，但有限的高尔夫体验什么，我想应该是我可以告诉，但最终你最好的设计取决于功能，范围和设计目标（如可扩展性）。开始与你最好的拍摄，编写针对它的测试，你的设计缺陷将会出现在你知道之前。 ：D

Finally, there is no right answer in design. I could tell you based on my extensive design experience but limited golf experience what I THINK it should be, but ultimately your best design depends on the features, scope, and design goals (like extensibility). Start with your best shot, write tests against it, and your design flaws will emerge before you know it. :D

后修改2：

我想你是过度解读埃里克·埃文的指导。我不相信他所说的话，你不能从四人公开播放器。

I think you are reading too much into Eric Evan's guidance. I don't believe he is saying that you can't expose Player from Foursome.