blocks|key|1989630|text|我不确定这类问题是否有正确的答案，因为应用DDD实际上取决于您要应用到的特定领域。如果您的实现能够满足业务需求，那么有些地方是完全有效的。在其他情况下，就像你提到的税收之类的，它不会。所以，我想说，你需要不断地问关于你的领域的问题，以充分了解你的需求是什么，然后再把它们转换成代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1989631|话虽如此，如果您有一个更复杂的场景，需要对外部世界有一些额外的知识才能得到发票的值，那么有一种选择就是在您的域中显式地表示这一点。在您的示例中，可能是一个InvoiceProducer，它可能具有如下的签名：|1989632|class+InvoiceProducer+{

++++public+function+__construct(TaxProvider+$taxProvider)+{
++++++++$this->taxProvider+=+$taxProvider;
++++}

++++public+function+invoiceFor(array+$items)+{
++++++++new+Invoice($items,+$this->calculateValue($items));
++++}

++++private+function+calculateValue(array+$items)+{
++++++++$sum+=+array_reduce($items,+function($acc,+$item){
++++++++++++$acc+%2B=+$item->value;
++++++++}

++++++++return+$this->taxProvider->applyTaxTo($sum);
++++}
}|code-block|syntax|javascript|1989633|另一种选择是使用某种策略模式，这将使您的实现非常类似于现在的方式，但是您可以按照您希望计算税收的方式传递您的调用：|1989634|public+function+getInvoiceValue(TaxProvider+$taxProvider)
{
++++$sum+=+0;
++++foreach($this->items+as+$item)+{
++++++++$sum+%2B=+$item->value;
++++}

++++return+$taxProvider->applyTaxFor($sum);
}|1989635|同样，它确实取决于您的特定域是如何工作的，但是，正如您所看到的，实现不应该有那么大的问题。更多关于它如何适合您的领域。|1989636|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I'm not sure if there's a right answer for these kind of questions, because applying DDD really depends on the particular domain you're applying it to. There are places where your implementation could be perfectly valid, if it satisfies the business needs. In others, like you mentioned with taxes and the like, it wouldn't. So I'd say that you need to keep asking questions about your domain to fully understand what your needs are before translating them into code.

Having said that, if you have a more complex scenario that requires some extra knowledge of the external world to come up with the value of an invoice, one option would be to represent that in your domain explicitly. In your example, that could be an InvoiceProducer, which could have a signature like:

<pre><code>class InvoiceProducer {

 public function __construct(TaxProvider $taxProvider) {
 $this-&gt;taxProvider = $taxProvider;
 }

 public function invoiceFor(array $items) {
 new Invoice($items, $this-&gt;calculateValue($items));
 }

 private function calculateValue(array $items) {
 $sum = array_reduce($items, function($acc, $item){
 $acc += $item-&gt;value;
 }

 return $this-&gt;taxProvider-&gt;applyTaxTo($sum);
 }
}
</code></pre>

Another option would be to use some sort of Strategy pattern, which would leave your implementation very similar to the way it is now, but you'd pass with your call the way you want the taxation to be calculated:

<pre><code>public function getInvoiceValue(TaxProvider $taxProvider)
{
 $sum = 0;
 foreach($this-&gt;items as $item) {
 $sum += $item-&gt;value;
 }

 return $taxProvider-&gt;applyTaxFor($sum);
}
</code></pre>

Again, it really depends on how your specific domain works but, as you can see, the implementation shouldn't be that big of a deal. Is more about how it all fits within your domain.

blocks|key|1989701|text|域对象中应该存在多少业务逻辑？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|1989702|所有这些(如果可能的话)。DDD的目的是捕捉您在域中的业务逻辑--这里可以使用各种战术模式来帮助您(集合、实体、值对象、域服务等)。|unstyled|1989703|域对象是类，表示域中的实体。|1989704|域中的类可以表示的不仅仅是实体。聚合、实体、值对象、域服务等都可以由域中的类表示。|1989705|但我对getInvoiceValue()并不确定。我们在这里操作其他域对象。|1989706|您给出的发票示例是聚合发票的典型示例--发票将包含InvoiceItems。getInvoiceValue()在这里很好。|1989707|在我们的例子中，发票是一个汇总。聚合根是发票本身，但它也是实体，对吗？但它有自己的身份(发票号码是唯一的)。|1989708|是的正确|1989709|那么InvoiceItems是什么呢？我可以直接从InvoiceItem存储库中获取它们(如果我应该创建这样的存储库)，或者我是否总是必须只对聚合进行操作？|1989710|这取决于您的用例。它有助于将写入和读取模型(CQRS)分开。如果您讨论的是读取端(即报告)，那么您将绕过域模型，并拥有表示您的读取模型的对象。这可能只是一个数据库查询。如果您讨论的是您的写端(即命令、域)，那么通常每个聚合根都有一个存储库。你的总根是什么是一个模型问题。您希望以这样的方式创建它们，以强制执行所有业务规则--在您的示例中，如果发票需要加载InvoiceItems以强制执行规则(例如，“每个发票不超过5项”)，则应该通过聚合根目录加载它们。|1989711|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|Y|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|10|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|11|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|12|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|13|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|14|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|15|8|@]|9|@]|A|$]]|$1|U|3|-4|5|D|7|16|8|@]|9|@]|A|$]]]|V|$]]

<blockquote>
 How much business logic should exist in Domain Objects? 
</blockquote>

All of it (if possible). The point of DDD is to capture your business logic in your domain - the various tactical patterns can be used here to help (Aggregates, Entities, Value Objects, Domain Services etc...).

<blockquote>
 Domain objects are classes, that represent entities in the domain.
</blockquote>

The classes in your domain can represent more than just Entities. Aggregates, Entities, Value Objects, Domain Services etc can all be represented by classes in your domain.

<blockquote>
 But I'm not sure about getInvoiceValue(). We operate here on other domain objects.
</blockquote>

The example you give of Invoice is a classic example of an Aggregate - Invoice would contain InvoiceItems. getInvoiceValue() is fine here.

<blockquote>
 In our case, Invoice is an aggregate. Aggregate Root is Invoice itself, but it is also Entity, right? It has its own identity though (invoice number that is unique). 
</blockquote>

Yes correct

<blockquote>
 What are InvoiceItems then? Can I fetch them directly from InvoiceItem repository (if I should create such), or do I always have to operate only on Aggregate? 
</blockquote>

It depends on your use case. It helps to split the write and read models apart (CQRS). If you are talking about the read side (i.e. reporting) then you bypass the domain model and have objects that represent your read model. This might just be a database query. If you are talking about your write side (i.e. commands, domain) then you would normally have a repository per aggregate root. What your aggregate roots are is a modelling question. You want to create them in such a way as they enforce all your business rules - in your example, if an Invoice needs to load InvoiceItems to enforce rules ("no more than 5 items per invoice" for example) then yes, they should be loaded through the aggregate root

blocks|key|2741421|text|域对象中应该存在多少业务逻辑？我偶然看到一些文章，我认为它应该尽可能小，并且只代表它的价值。|type|blockquote|depth|inlineStyleRanges|entityRanges|data|2741422|注意贫血域模型，它几乎完全由数据组成，缺乏行为。DDD是关于创建一个行为丰富的域模型。因此，可以将逻辑添加到域类中。|unstyled|offset|length|2741423|DDD强调良好的面向对象设计，将方法和数据集成在一起，从而促进了内聚系统的高度发展。|2741424|entityMap|0|LINK|mutability|MUTABLE|url|http://www.martinfowler.com/bliki/AnemicDomainModel.html|1|https://en.wikipedia.org/wiki/Cohesion_(computer_science))^0|0|2|5|0|0|W|4|1|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@$E|U|F|V|1|W]]|A|$]]|$1|G|3|H|5|D|7|X|8|@]|9|@$E|Y|F|Z|1|10]]|A|$]]|$1|I|3|-4|5|D|7|11|8|@]|9|@]|A|$]]]|J|$K|$5|L|M|N|A|$O|P]]|Q|$5|L|M|N|A|$O|R]]]]

<blockquote>
 How much business logic should exist in Domain Objects? [...] I came across articles where I assumed it should be as tiny as possible and only represent its values.
</blockquote>

Beware of the <a href="http://www.martinfowler.com/bliki/AnemicDomainModel.html" rel="nofollow">Anemic Domain Model</a> that almost exclusively consists of data and lacks behavior. DDD is about creating a behavior-rich domain model. Thus it's fine to add logic into domain classes.

DDD emphasizes good object oriented design, putting methods and data together, thereby promoting highly <a href="https://en.wikipedia.org/wiki/Cohesion_(computer_science)" rel="nofollow">cohesive systems</a>.

I've been very busy with trying to understand the concepts of ddd and Model layer lately. Read tons of articles, examples, Q and A's, spent many hours on it. And still I'm not sure if I got some principles right.

One of them is the answer to the question: How much business logic should exist in Domain Objects? Some sources say Domain Objects should be attached with the whole business logic, on the other hand, I came across articles where I assumed it should be as tiny, as possible and only represent its values. It makes me really confused.

In my understanding, domain objects are classes, that represent entities in the domain.

So, lets for example, go with Invoice entity. Each invoice consist of its items. To compute invoice value, we must sum all items values (it's very simple example, in the real world there would be cases like adding tax, computing paid value, etc)

<pre><code>class Invoice
{
 public $id;
 public $items = [];
 public $status;

 const STATUS_PAID = 'paid';
 const STATUS_NOT_PAID = 'not_paid';

 public function isPaid()
 {
 return $this-&gt;status == self::STATUS_PAID;
 }

 public function getInvoiceValue()
 {
 $sum = 0;
 foreach($this-&gt;items as $item) {
 $sum += $item-&gt;value;
 }
 return $sum;
 }
}
</code></pre>

In my understanding, method isPaid() is in the right place. It refers to its own data. But I'm not sure about getInvoiceValue(). We operate here on other domain objects. 

Maybe we should use domain objects just to represent data only, but use some decorators to perform more advanced tasks?

Thanks in advance.

DDD, PHP. Domain Object and Business Logic

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

最近我一直忙于理解ddd和模型层的概念。阅读大量的文章，例子，Q和A，花了很多时间在上面。但我还是不确定我是否有正确的原则。其中之一就是对这个问题的回答:域对象中应该存在多少业务逻辑？一些消息来源说，域对象应该与整个业务逻辑相关联，另一方面，我遇到了一些文章，我认为它应该尽可能小，并且只代表它的值。这让我很困惑。据我理...

问DDD，PHP域对象与业务逻辑
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问DDD，PHP域对象与业务逻辑EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问DDD，PHP域对象与业务逻辑
EN