我是域驱动设计的新手，我读了很多关于它的书。我开始了我认为尊重DDD原则的第一个实现。
但现在，我想知道一些事情：为了定义子域和上下文，我从定义良好的UI设计开始。它们很好地描述了当你想与应用程序交互时所采取的每一个步骤。
你认为这是一个很好的起点吗(当然，我也从领域专家那里了解到了(？我的意思是，UI定义用例不是吗？
示例：
你有一个管理面板，通过这个面板，你可以管理公司。因此，我得出结论，我的子域是Administration/，它的上下文之一是Company/。
所以我最终得到了这样的东西：
src/
Administration/
Company/
Domain/
Command/
Ports
它是设计拙劣的域名吗？
我真的很想听听你对此的看法。
祝你今天愉快。
-------编辑------
正如@Luca Masera所说，我的例子有点太小了。
所以举更多的例子，我最终会得到这样的东西：
src/
Administration/
Company/
Domain/
Company.model
Employees.collection
Commands/
AddEmployeeToCompany.command
GetAllEmployeesForACompany.query
[...]
Employees/
Domain/
Commands/
[...]
FrontEnd/ <--- didn't really think about the naming yet
Contracts/
Domain/
Contract.model
CompanyId.id
Employee.model
Commands/
ChangeContractForEmployee.command
实际上我真的不明白，因为如果你最终在每个ui区域上分割同一个域，你只做了一个样本。我所知道的是ui定义了用例，但它们的实现方式不应该定义域的设计。
如果你有一个Administration和一个Frontend，并且你将公司域分为两个，那么答案是否定的，这不好。公司域应该将其所有逻辑封装在一个包中，而不是分散在几个上下文中。
例如，在我的上一个应用程序中，我必须管理用户Absions。它们有几种类型：假期、疾病、豁免和其他一些。我还有另一个概念，Prospects：它们从一个子系统开始，为每种类型的缺勤提供一般信息。
当用户启动应用程序时，第一个入口点在Prospects域中。ui加载页面，然后在Javascript和Ajax的帮助下，将页面的一部分询问给其他域。与域的每一次进一步交互都由该域的ui(在基础结构层中实现(管理。
---编辑后---
我不会做这样的事。正如我之前所写的，通过这种方式，您最终会在每个宏区域中拆分域逻辑。因此，你失去了DDD的所有优势。
我详细阐述了一下：稍后，在管理中，如果您需要了解合同，您会怎么做？
无论你使用什么架构，你都会有：
src/
contracts/
infrastructure/
*** My way to manage the UI interactions ***
ui/
frontendA/ (it could be *hr_team*)
frontendB/ (it could be *managers*)
frontendC/ (it could be *employers)
application/
domain/
companies/
infrastructure/
*** My way to manage the UI interactions ***
ui/
frontendA/ (it could be *hr_team*)
frontendB/ (it could be *managers*)
*** no employers actions are planned ***
application/
domain/
在基础结构中，您将实现允许使用应用程序层内的代码与域交互的控制器。角色之间有些重叠(有些雇主可能是经理，有些是hr_team的其他部分(，但功能上没有重叠。
通过这种方式，您仍然可以将域(契约(的逻辑放在一起，但最终可以很好地拆分每个角色的功能。