问题标签 [architecture]

我试图理解 DDD 背后的概念，但我发现仅通过阅读书籍很难理解，因为它们倾向于以相当抽象的方式讨论该主题。我想在代码中看到一些好的 DDD 实现，最好是在 C# 中。

有没有在开源世界中实践 DDD 的项目的好例子？

过去一年，.NET 社区 (ala Qi4j ) 似乎对 COP 产生了一些兴趣。一些人已经推出了自己的 COP 框架（请参阅下面的链接），看起来 .NET 4.0 的 Dynamic Dispatch 和 MEF 可能在任何 .NET COP 框架中都有潜在的作用。

一方面，其中很多似乎可以追溯到 System/38 天的想法（是的，我是个老家伙），但另一方面，它似乎也很适合奥斯陆（建模和存储库）。谁能评论微软是否在 COP 上做任何工作？

最近的一些 .NET COP 框架工作：

亨德利·卢克 -滚动你自己的 COP

Yves GoEleven.com -警察 - 概念证明

安德斯·诺罗斯 -把戏还是特质？使用 C# 进行面向复合的编程

Magnus Mårtensson - Unity 应用程序块上的面向复合的编程峰值

我有一个关于 Java 中的 MVC Web 应用程序的非常基本的问题。

从原始 JSP 的早期直到像 Seam 这样的当前技术，一个非常基本的模式一直是从最初接受请求的控制器到视图层的内部调度，该视图层创建要发送到客户端的输出。

这种内部调度通常是通过使用 URL 向 servlet 容器请求新资源来完成的（尽管该机制可能通过额外的配置层隐藏）。这些 URL 的映射由相同的 web.xml 完成，该 web.xml 还定义了到外部的“真实”URL。

除非采取特殊措施，否则通常可以直接访问视图层。见证Seam“注册”演示，您可以在其中绕过“register.seam”并直接转到“registered.xhtml”。这是一个潜在的安全问题。至少，它泄露了视图模板源代码。

我知道这只是一个基本的示例应用程序，但也很奇怪，需要采取任何额外的措施来声明这些内部资源对外部不可见。

限制 URL 入口点的最简单方法是什么？

是否可能有类似“WEB-INF”目录的东西，一个只能由内部请求访问的神奇 URL 路径组件？

Java 和 Oracle 都有一个称为 Date的时间戳类型。开发人员倾向于将它们当作日历日期来操作，我已经看到这会导致令人讨厌的一次性错误。

1. 对于基本日期数量，您可以在输入时简单地切断时间部分，即降低精度。但是，如果您使用日期范围（例如：9/29-9/30）执行此操作，则这两个值之间的差异是 1 天，而不是 2。此外，范围比较需要 1）截断操作：start < trunc(now) <= end，或2）算术：start < now < (end + 24hrs)。不可怕，但不干燥。

2. 另一种方法是使用真正的时间戳：9/29 00:00:00 - 10/1 00:00:00。（午夜到午夜，因此不包括 10 月的任何部分）。现在持续时间本质上是正确的，并且范围比较更简单：start <= now < end. 对于内部处理来说当然更干净，但是结束日期确实需要在初始输入 (+1) 和输出 (-1) 时进行转换，假设在用户级别使用日历日期隐喻。

您如何处理项目的日期范围？还有其他选择吗？我对您如何在等式的 Java 和 Oracle 方面处理这个问题特别感兴趣。

I've organized my code hierarchically and I find myself crawling up the tree using code like the following.

I'm not drilling down into the task object; I'm drilling up to its parents, so I don't think I'm losing anything in terms of encapsulation; but a flag is going off in the back of my mind telling me there's something dirty about doing it this way.

Is this wrong?

在 32 位 CPU 上，一个整数是 4 个字节，一个短整数是 2 个字节。如果我正在编写一个使用许多数值的 C/C++ 应用程序，这些数值总是在提供的短整数范围内，使用 4 字节整数还是 2 字节整数更有效？

我听说它建议 4 字节整数更有效，因为这适合从内存到 CPU 的总线带宽。但是，如果我将两个短整数相加，CPU 是否会将这两个值并行打包一次（从而跨越总线的 4 字节带宽）？

我需要以可靠/事务的方式为外部系统排队事件和任务。使用 MSMQ 或 ActiveMQ 之类的东西看起来很诱人，但事务部分变得复杂（MSDTC 等）。

我们可以使用数据库（SQL Server 2005+、Oracle 9+）并实现更轻松的事务支持，但排队部分变得更丑陋。

这两条路线似乎都不是那么好，并且充满了令人讨厌的陷阱和极端情况。

有人可以在这件事上提供一些实用的指导吗？

想一想：E/C/A 或者一个定时任务引擎，每隔一段时间就会唤醒，看看此时是否有定时任务需要运行（即 next-run-date 已经过了，但是 expire-date 还没到到达）。

我在这里可能是个例外，但我从未在一个拥有超过三个开发人员和/或五个人的团队中工作过。我们仍然可以设法完成工作（不知何故）。

是否有适合这种“极端”场景的软件开发过程？而且，如果你作为一个独立的程序员工作，你是否可以适应你的日常生活，使其更可预测、更连贯、更有记录，并且仍然可以完成工作？

我有一个系统可以将计算应用于一组数字（具体细节并不相关）。系统用户可以应用许多计算集，并且经常添加新集。目前，当需要将一组新的计算添加到系统中时，它们会添加到代码库中并发布新版本的系统。我希望能够在系统中添加新的计算集，而不必发布一个全新的版本，并且让这些新的计算自动对系统用户可见。目前，为每组计算创建一个新函数，并将包含适当函数名称的记录添加到系统表中。这些记录对系统用户可见（函数名称当然是别名！）然后从列表中选择它们。

这是我继承的一个 VB6/Access 应用程序，目前正在用 VB.NET 和 SQL Server 重写。

有人对如何最好地做到这一点有任何建议吗？

我继承了一个使用 Struts、Spring 和 Hibernate 的大型 Java 应用程序。我每天处理的类和接口有：Struts Actions、Struts ActionForms、值对象、服务接口和实现、DAO 接口和实现以及实体。我很清楚其中大多数的方式和原因，除了我不确定 ActionForms、Value Objects 和 Entities 之间的职责是否正确分离。我还应该提到域模型（即所有实体）不包含太多（如果有的话）真实的业务逻辑。这本质上是一个 CRUD 应用程序，大部分真正的逻辑都在数据库中（糟糕！）。无论如何，我想知道几个不同的 Java 相关问题：

1) Entities 和 Value Objects (VOs) 之间似乎没有太大区别，并且当它们以任一方向通过服务层时，必须编写大量代码才能转换为另一个（Struts Actions 只处理VOs、DAOs 只处理实体）。因此，VO 和实体似乎有些多余。为什么两者都有？

2）VO<->实体翻译代码应该去哪里？服务层、实体、VO？

3) VO 被直接放入ActionForms 并直接绑定到JSP 中的标签（例如）。这是一个好习惯吗？如果不是，那么合适的设计是什么？

4) 不清楚如何正确处理值对象中的外键依赖关系。例如，某些 VO 有一个类型字段，在数据库术语中，它表示与类型表的外键关系。在 UI 中，这转换为一个下拉字段，允许用户选择类型，或者一个标签，仅显示类型的文本表示（取决于它是哪个屏幕）。现在，VO 是否应该具有类型 ID 的属性、类型的文本表示，或两者兼而有之？谁负责在两者之间进行翻译，何时翻译？

5) VO 有一个字段作为其数据库 ID。我以为VO没有身份？这是怎么回事？

我希望这些问题足够笼统，足以引起人们的普遍兴趣。在这种类型的架构中，这似乎会一直出现。

另外，我怀疑这个架构对于这个应用来说太重了，如果你有更好的建议，请继续。但我主要对上述问题的答案感兴趣，因为不同的架构是我现在无法进行的长期重构。