不断发展的业务 - DDD 与否？
我有一个项目，我已经在研究传统的 3 层架构（实体/业务/UI），并且我正在应用存储库模式和 IoC。
这里的想法是，我们是企业主，但业务正在发展，不能说实际上有一个最终的领域并准备好实施。我的实体不包含复杂的业务，我将业务逻辑保留在业务层中。
尽管我们已经在使用存储库模式和 IoC，但是迁移到 DDD 真的有额外的价值吗？我应该将我的业务合并到我的实体中吗？
[编辑] 假设这是最好的做法，会：
将实体层合并到业务层中而不是分开
<块引用>（避免循环引用，因为实体可以有行为，甚至 以我的理解调用业务服务）
将一些业务服务行为移动到适用的域实体中是拥有域模型的第一步？
[更多]
http://en.wikipedia.org/wiki/Domain -driven_design
- 您的域名并不简单
- 项目团队对 OOP/OOD 拥有经验和兴趣
- 您可以联系领域专家
- 您有一个迭代过程
I have a project where I'm already working on a traditional 3 layers architecture (Entity / Business / UI), and I'm applying the repository pattern and IoC.
The idea here is that we are the business owners yet the business is evolving and cannot say there is actually a domain final and ready to be implemented. My entities do not contain complex business and I'm keeping my business logic in the business layer.
Is there really an extra value from moving to DDD although we are already making use of the repository pattern and IoC, should I incorporate my business into my entities?
[Edit] Assuming it is the best thing to do, would:
Merging the entity layer into the business layer rather than being separate
(to avoid cyclic references since entities can have behavior and even
call business services in my understanding)Moving some of the business services behavior into the domain entities where applicable be the first step to have a domain model?
[More]
http://en.wikipedia.org/wiki/Domain-driven_design
Prerequisites for the successful application of DDD:
- Your domain is not trivial
- The project team has experience and interest in OOP/OOD
- You have access to domain experts
- You have an iterative process
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
DDD的主要思想不仅仅是使用存储库，它与IoC无关，它是关于拥有一种业务通用语言，并根据反映您业务的实体和值对象来设计您的领域层，这样您就可以需要以面向对象的方式真正对其进行建模，其中对象封装数据并包含行为，这样应用程序在业务逻辑方面将更具可维护性，并且可以通过利用抽象、多态性、组合等面向对象的技术进行扩展......
所以答案是的
The main idea of DDD is not to just use the repository, and it has nothing to do with IoC, it is about having a business ubiquitous language, and design your domain layer in terms of entities and value objects reflecting your business, this way you need to really model it in an object oriented way where objects encapsulates data and include behavior, this way the application will be more maintainable in terms of business logic and will be extensible by utilizing object oriented techniques like abstraction, polymorphism, composition, ...
So the answer would be yes
您可能会对领域模型和 DDD 感到困惑。领域模型是一种架构模式，其中业务实体被实现为 OO 类并利用存储库模式，而 DDD 是一组用于分析和建模业务的过程和原则。 DDD 实际上是一种更精致、更正式的领域模型实现方式。
无论如何，您不需要一个“最终”和“准备好实现”的域，因为域模型和 DDD 都是为不断发展的域模型而设计的。
您说业务层包含逻辑而不是实体，而实际上实体就是业务层（或域）。
我想说，实现领域模型的开销是最小的，而且从长远来看，随着模型不断发展，几乎总是值得的。
You may be getting confused between Domain Model and DDD. Domain Model is an architectural pattern in which business entities are implemented as OO classes and which utilises the repository pattern, whereas DDD is a set of processes and principles for analysing and modelling the business. DDD is really a more refined and formal way of implementing Domain Model.
Anyhow, you should not need a domain that is 'final' and 'ready to be implemented' as both Domain Model and DDD are designed for an evolving domain model.
You say that the business layer contains the logic and not the entities, when in fact the entities ARE the business layer (or Domain).
I would say the overhead in implementing Domain Model is minimal, and almost always worth it in the long term with an evolving model.
这几乎不是是/否问题。
业务层的方法是否仅适用于某个类的单个实例？将其移至类内。
它是否适用于集合、几个不同的类和/或逻辑更复杂？可能没有通用的答案，无论您决定如何，都不要引入循环依赖项并尝试破坏现有的依赖项 - 当需要进行一些重构时，迟早您会对此表示感激。
完成后，检查 API 并尽可能从中删除。
This is hardly yes/no question.
Does a method from business layer work only with a single instance of some class ? Move it inside the class.
Does it work with collection(s), several different classes and/or the logic is more complex ? There is probably no universal answer, whatever you decide do not introduce circular dependencies and try to break existing ones - sooner or later you'll be grateful for that when some refactoring is necessary.
After you're done, inspect API and remove from it as much as possible.