问题并不是真正关注DDD，而是想知道是否有任何方法可以模拟松散耦合的域模型。 我的意思是什么？ 我为一个软件HR编辑工作，我们计划从头开始一个新的应用程序。 我们对我们为150位客户所做的所有项目进行了审核，事实上我们不能说从DDD的角度来看有一个有效的域模型。
为什么？ 因为每家公司都以不同的方式处理人力资源，具体取决于公司的规模等等。
当然，我们可以识别人力资源领域的社区实体，如：工作，提供，合作者，技能等，但它们与客户A和客户B的关联方式不同。因此，从域模型的角度来看，我们可以不能说实体A有对实体B的引用，它具有一系列技能，因为对另一个客户来说不是这样。
即使我们80％的客户能够设计满足90％需求的模型，我们也不会牺牲其他客户，另一方面也希望有一个产品可以通过特定的开发来解决不同的问题。
我们研究了BPM解决方案，但这并不符合我们的需求。 另一方面，我无法想象你如何处理我们需要的东西。 实际上，实体之间的链接应该在运行时从每种客户端的一种参数，xml等“完成”。 我们不想编写另一个应用程序，因为域模型稍有变化。 如果没有适当的域模型，这可能会非常疯狂，但基于消息传递的东西可以帮助我们。
希望你对此有所了解。 你是怎么处理这种情况的？
谢谢，
The question doesn't really concerne DDD but would like to know if there is any way to model a loosely coupled domain model. What I mean by that ? I work for a software HR editor and we're planning to start a new application from scratch. We did an audit of all projects we did for our 150 customers and the fact is that we can't say there is one valid domain model from the point of view of DDD.
Why ? Because each company deals with HR in different ways depending on how big the company is, etc. etc.
Of course we can identify commun entities in HR domain like: job, offer, collaborator, skills, etc, but they are not linked the same way for the client A and the client B. So from the point of view of Domain Model we can't say that Entity A has a reference to Entity B which have a collection of skills because it won't be true for another customer.
Even if for 80% of our customer we can design a model that adresses 90% of needs we won't sacrify the rest of the customers and on the other hand would like to have a product witouht doing specific development to address differents concerns.
We looked at BPM solutions but that doesn't fit well with our needs. On the other hand I can't imagine how you can handle what we need. In fact the links between entities should be "done" at runtime from a sort of parameter, xml, etc. for each client. We would like to not have to code another application because the domain model has slightly changed. This could be completely insane to not have a propper Domain Model but something based on messaging could help us.
Would like your thoughs about that. How did you deal with such a situations.
Thanks,
最满意答案
域模型的目的是封装常见的行为和关系 。 虽然您可以（并且应该）松散地耦合您的实现，但是您可以通过配置驱动的方式进行限制。
如果你继续将其推向越来越多的可配置性，那么在某个时刻它将不再是一个领域模型而是成为一个框架 。 然后，您可以使用框架来定义特定的域模型。
编写框架确实非常非常困难，因此我不认为用这个明确的目标启动项目是一个可行的计划。
如果可以，请从公共代码库开始，每次获得客户特定请求时，重构内核，以便将客户功能实现为插件 。
有了大量的时间，运气和技巧 ，您就可以将该内核发展为特定领域的框架 。
The purpose of a Domain Model is to encapsulate common behaviors and relationships. While you can (and should) loosely couple your implementation, there are limits to how configuration-driven you can make it.
If you keep pushing it towards more and more configurability, at a certain point it will stop being a Domain Model and instead become a Framework. You can then use the Framework to define specific Domain Models.
Writing a Framework is really, really hard, so I don't think it would be a feasible plan to start a project with that explicit goal.
If you can, start with a common code base and every time you get a customer-specific request, refactor the kernel so that you can implement the customer feature as a plugin.
With lots of time, luck and skill, you may be able to evolve that kernel into a Domain-Specific Framework.
更多推荐
发布评论