关于良好的域分解

或如何制作可以工作的物体

我使用一些特征来检查我的软件。 可能主要的是重用抽象原理 。 它说只有在有多个实现的情况下，抽象才是好的。 换句话说，它提出抽象应该是抽象的。

Mark Seemann在关于解决方案空间方法的一篇不错的文章中指出，这种方法可以导致更好的抽象。

但是OOP开始的时间比开始编写代码的时间要早​​得多。 与您的域专家交谈时，它开始。

了解你的问题

柏拉图在他与Phaedrus的对话中说 ，我们的设计应该是领域驱动的，并且应该从问题空间开始。 他描述了以下原理：

[原则]感知并把一个分散的细节集中在一个概念中，以便人们可以通过定义明确他想解释的特定事物； 就像现在一样，在谈到爱（我认为爱神在这里的意思）时 ， 我们说出了他的 名字 并定义了它是好是坏 。 当然，这意味着话语获得了清晰和一致 。

这与Parnas将系统分解为模块的方法产生了共鸣。

分解问题空间

当我确定了自己的领域后，便着手进行分解。 柏拉图描述了分解必须具备的主要特征：

[原理]按照坏的雕刻师的方式，将事物再次划分为自然的关节所在的类，并且不试图破坏任何部分。

事实证明，过程编程对于良好的分解没有很好的指导作用。 数据或过程都不适合该目的。 但是是什么呢？ 好吧，由于我们在这里进行面向对象操作，因此答案就是行为就不足为奇了。 上面提到的自然关节是对象的边界。
顺便说一句，相同的原则适用于标识服务边界 。

实际后果

第一个是右分解产生的元素是可组合的，而抽象的数量相对较少。 这不是科学的陈述，更像是经验性的陈述。 看一下化学：元素周期表中的元素少于130个。 欧几里得几何 ：13个公理。 代数：10个数字和一堆运算。 自然可以满足重用的抽象原理。

可组合性意味着实体共享相同的接口。 这意味着我们周围有很多可替换的东西。 我不在乎什么公共汽车将我带到办公室-我只在乎它的数量。 我不在乎我穿什么牛仔裤-大小可能是唯一标准。 或我使用什么椅子，桌子或笔。

隐喻指导您寻找对象

大卫·韦斯特 （ David West）在他的《 对象思维》一书中描述了一些有用的隐喻，这些隐喻描述了正确的分解。 它们都适用于问题空间，即领域。

第一个是乐高。 乐高（Lego）中有很多零件，但是零件类型却少得多。 并且所有部分都是高度可组合的。
第二个是人的隐喻。 我在看书之前就用过它，所以对我来说这是最自然的一本书。 更具体地说，我不仅会让人联想到一个人，而且还会做出决定的成年人，告诉别人对与错，并决定如何做他或她应该做的任何事情。
第三个是剧院。 每个演员都知道如何扮演自己的角色，每个演员都可以替换一些同事，这很好。
我喜欢的对象协作的隐喻是蚂蚁。 科学证明（甚至在书中也有链接！），绝对没有编排蚂蚁。 他们都是平等的。 因此对象应该。

例

我试图在设计DateTime库时应用这些原理。
我基本上需要两件事：以任意格式创建datetime对象，并以任意格式输出它们。 因此，有两个接口-ISO8601DateTime和FormattedDateTime 。 另外我还需要一个界面来间隔工作。 三个目录对应于这些接口。
我还需要相对指定日期时间。 因此，我有一个时间轴目录，其中包含三个类：过去，现在和将来。
最后，我想要一个比较功能，我用两个类来表达它： Min和Max 。 可以与它们进行任何比较。

这是此库可以表达的示例：

// outputs true

var_dump(
(new Max(
new Future(
new Past(
new FromMilliseconds(
(new ToMilliseconds(
new FromISO8601('2017-08-18T15:08:13+04:00')
))
->value()
),
new ISO8601Interval('P1Y2M21DT24H56M26S')
),
new ISO8601Interval('PT23H')
),
new Now()
))
->equalsTo(new Now())
);

对象是可组合的，并且有比接口更多的类。 因此我的目标得以实现。

这个库目前只是一个实验，它缺少一些功能并且已经存在一些问题（我不喜欢在equalsTo()方法中复制粘贴），但是整个分解似乎还不错。

总结一下

因此，从问题空间（您的域）开始。 使用行为作为分解标准。 记住隐喻。 让可组合性成为您的目标。

From: https://hackernoon.com/on-good-domain-decomposition-385ee8ce5a3